Every year banks spend millions managing incidents that impact their ability to process payments. A large proportion of these costs are frequently swallowed up with the issue’s investigation, repair and remediation, which is often still quite a manual process. These incidents can also generate compensation claims due to client SLA breaches, and considerable fines as regulators impose penalties. Furthermore, high profile events can even cause reputational damage, and following the recent influx of competitive offerings, ultimately threaten client retention efforts.
A major reason why these costs are so high is that when an issue occurs those involved in the incident’s management can struggle to access the information needed to make fully informed decisions in a timely manner. The type of insight that enables them to determine, for instance, exactly where in the process the problem has occurred, how it has impacted downstream activities, precisely which payments have been affected and the clients they belong to.
It’s not that this information is completely unattainable, it isn’t. But the way in which banks often monitor these environments means that it needs to be manually assimilated from multiple sources. This can prove laborious and the longer it takes, the more time the issue has to mature and costs to extrapolate.
To understand why this is often the case involves first comprehending just how complex the payment processing environments operated by many banks have become. Having evolved organically in response to emerging client and regulatory needs, many now feature:
- Deep-rooted legacy technology, onto which multiple new functions may have been bolted over the years
- Duplicate systems and processes inherited through merger and acquisition activities
- And third party systems.
The culmination of which is often a very complicated patchwork of systems and processes, operating in siloes. Across these systems and processes, runs an intricate network of payment paths traversing multiple shared environments.
Banks have commonly taken a very traditional approach to monitoring their payment processes, chiefly concentrating on assessing infrastructure health. The siloed nature of these structures often means this happens on a system-by-system or process-by-process basis, and infrastructure self-monitoring techniques are frequently employed. The problem is that in the new world of faster payments, where incident managers are increasingly required to make immediate decisions, and need relevant, actionable insight to do so, the delays these approaches can introduce are starting to present significant problems.
Infrastructure health monitoring
Take for example the focus on infrastructure health. This style of monitoring is very valuable at a technical level, as it enables users to identify and investigate the issue’s root cause. However, because techniques often concentrate on systems, networks and applications, instead of tracking the actual transactions being processed, when an incident occurs identifying exactly which payments and clients have been impacted can prove very time consuming. Without this information upfront, customer-facing teams can find they are unable to proactively manage the experience of impacted clients. For these groups, knowing a network link is down is of little value what they actually need to know is what is currently happening to the payments belonging to the client on the other end of the phone and when these payments will be fixed.
Furthermore, by only focusing on the infrastructure, and not the actual payments, there’s also a strong chance that a transaction requiring manual repair could go undetected until it’s too late. By which point the payment may have missed its cut-off time, potentially generating an SLA breach and associated charges.
Infrastructure self-monitoring techniques
This is a problem amplified when system self-monitoring techniques are added to the mix. If a self-monitored system goes down, so can any kind of chance of quickly understanding which payments were being processed at its point-of-failure. For as long as it takes to manually collate this insight, client-servicing teams can struggle to provide sufficiently detailed answers regarding specific payments - thus further delaying remediation efforts.
System-by-system or process-by-process monitoring
The issue with individual system or process monitoring is that it only provides a snapshot of what is happening at a particular point in the end-to-end payment process. In doing so, potentially risking that emerging stability and efficiency threats go undetected.
Payment processes can easily include 20-30 different systems, so determining an issue’s location can require looking at 20-30 separate screens. This is before engineers can even start to investigate the issue by collating results gleaned from multiple systems, and the business can categorise the incident’s seriousness.
Furthermore, because these systems often operate in silos, a payment may be allocated a different identifier by each system. This can present complications when a transaction is lost, as searching using the payment’s ID requires first identifying which system it was in when it went missing. Determining this isn’t straightforward; the payment’s route will depend on the transaction’s individual instructions, jurisdictional routing rules and how it performs at various checkpoints. In some firms resolving this problem can require assembling teams of 20+ representatives, for hours at a time (one from every group responsible for each siloed system). Therefore, generating significant resource costs.
It’s time for a new approach
Without timely access to actionable insight, incident managers are likely to continue to struggle to curtail developing issues in a cost and time efficient manner. However, this doesn’t need to be the case. Recent advancements in monitoring technology are now enabling the industry’s more innovative players (even when they have non-supported, complex existing systems) to overcome these challenges, by providing immediate access to the type of information needed to make effective decisions.
Contemporary approaches now center on accurately tracking and analysing the real time status of the actual payments moving across complete processes, from their point-of-entry through to final posting. This enables emerging issues at any stage to be instantly detected and because the end-to-end path can be visualised in a single view, the downstream impact of a component’s degradation can be quickly understood.
By taking a top down business-level approach, the technology’s ability to detect problems at the infrastructure level is still supported, but it also means that adopters can very easily access the insight necessary to nail down exactly which payments the incident has affected, where it happened and the clients impacted.
Additionally, by continuously comparing how payments are currently flowing to past trends, recent advancements are now being used to proactively avoid SLA breaches occurring to start with by, for instance, alerting users to payments approaching their cut-off times that haven’t completed enough stages for this to be possible without manual intervention.
Furthermore, the latest advancements in transaction tracking technology are even able to get around the problem of quickly finding missing transactions, by allocating each payment an independent ID the very moment it enters the payment process. This avoids the need to change underlying systems and means if the payment is lost, regardless of what system it’s in at the time, it can be located using a single identifier.
Ultimately, these approaches empower all teams involved in the incident’s management to more effectively investigate, resolve and remediate issues, providing the relevant, actionable insight to enable this to happen in a more cost and time efficient manner.
If you’re interested in learning more about this new approach to instrumenting payment environments please download our recently released white paper.
By Daniella Huggins, Global Marketing Manager, Velocimetrics.