In this real-time financial transaction monitoring demo, Striim monitors financial transactions and correlates activity with infrastructure log data. This solution leverages RDBMS change data capture to capture transactions and correlates them with web logs and infrastructure logs to identify emerging problems proactively. This allows timely assignment of resources, addressing issues before they turn into bigger challenges or penalties and communication with stakeholders to set expectations and reduce the impact.

To learn more about Striim’s solutions in financial services, go here.

To learn more about the Striim platform, go here.

 

Unedited Transcript:

Hi, I’d like to walk you through an application we built to do real-time financial transaction monitoring. It sources data through change data capture processes and analyzes that data. Then visualizes it in a dashboard and sends alerts for unusual activity. The project is for Global Financial Services Company. They had an issue where outages in their processing or through dependencies in other networks were not noticed. Immediately. They would discover such things through end of day reports or support calls from customers. This could result in penalties for breaking SLAs with customers. That’s an overall bad customer experience. The goal of the project is to improve customer experience and revenues by ensuring SLAs were always met. This could be achieved by monitoring and analyzing the real time flow of financial transactions, displaying all this information in a monitoring dashboard and alerting for issues that may break SLAs so they could act immediately.

All of their transactions are written to a central database. We capture that data in real time through change data capture and utilize a time window to look at aggregate changes over time. We monitor the overall transaction volume and slice and dice this into various other dimensions. This is all displayed on the dashboard.

Additionally, we look at the ratio of approved to decline transactions and specifically monitor the decline rate triggering an alert if their rate increases by 10% or more in any five minute period. These alerts can be sent by email or SMS and can be accessed through the dashboard. So if we take a look at the dashboard, you can see the overall approval rate is being monitored. We’re monitoring the overall transaction value. We’re also looking at things, a point of view of the networks that are utilized, uh, under the covers. Okay. She do the transactions and the location in which those things are happening. You’ll notice that we are receiving alerts and these alerts are indicating, uh, that calculation. We mentioned that the decline rate has increased by more than 10% in the last five minutes. The dashboard allows us to drill down into various things so we can look at the transaction volume by the various different types of transactions. So debit, ATM check and, and credit. We can also look at the uh, approval to decline rate. So if we take a look at how things, uh, viewed over time, we can see the overall approvals and these are the different types of declines you can get. We can drill down by state and see the overall transaction rate over time for a particular state. And also if we want, we can view all of the states together.

We can also look at things by the different networks that are being used. All of this data is being generated and analyzed through a backend data flow. Let’s take a look at this. Data flow is defined in this application. There’s been running here,

The application is taking data capture through CDC and passing it through all these sub-flows that are doing all of the analysis. We can look at the data coming through at any point.

Let’s take a look at one of the sub-flows that’s doing analysis of the transaction volume by card type. This is taking the data in this window and it’s processing it using a query. All of our queries are continuous queries that run in memory defined through sequel and all of the processing in our platform is done through queries, so this particular query is taking the raw data as being put into this window and it’s generating data every minute that is grouped by the card type and that is going into the store. We take another look at another flow. This is the flow for the declined transactions. This does a similar thing calculating the aggregates of the decline rate over that one minute window, but it also puts it into another window so he couldn’t look at at the beginning and end of a five minute period.

It’s then checking to see whether the decline rate has changed by 10% within that time. If that’s the case is generating an alert and it’s also storing it so that we can see it in the dashboard. All of these data flows are utilized to produce the data that you see in a dashboard and the dashboard is then designed using our dashboard builder. The dashboard was also built using our product. The dashboard has a number of pages associated with it and you can create all of the visualizations on the page through our dashboard editor. If we take a look at one of these visualizations, then you see that it is powered by a query, is communicating with the back end. This is querying those results we saw in the flow and displaying it in the visualization. You have a choice of visualizations. You can drag them onto the page and build your dashboards really, really quickly. Thank you for viewing this demonstration. More information is available on our website Striim.com.