Five things transaction banks need to test in production
As a transaction bank, you want to control quality before your new or changed transaction service is put into production. However, some things can only be tested after they are launched into your production environment. In the risk-allergic payments domain, understanding this will prevent you from engineering complex and expensive quality assurance (QA) solutions that have no effect. Read carefully. Here is the list of things you need to test in production.
1. Your payment service in the customer’s environment
How will you know if your new, enriched or changed payment service will work in the customer’s environment? Example: A large international bank launched a new feature to its identification service. The feature functioned and performed well, considering operational availability, processing performance and avoidance of customer complaints. However, one out of ten login trials failed from a customer’s perspective. It appeared to be an error in one of the servers used one out of ten times. Even though this seems a minor issue, it does impact the user’s experience without the knowledge of the bank. What else does this bank not know about its delivered experience?
2. Your payment serv,ice in conjunction with all other services
Does your new, enriched or changed service work in the network of related services like authentication, authorisation, reporting and billing? Example: a bank developed a new transaction service. However, it was not able to send out the correct bill.
3. The cross-bank payment service
How will you know that your transaction route, including all its reporting, will work when the transaction is sent to another bank? Example: A bank is converting to the ISO XML standard. Transaction informa was sent from the initiating bank did not fully arrive at the recipient bank. This caused reconciliation issues with customers. By pre-informing customers of this issue, formal complaints can be avoided.
4. Compliance checks across the network
How will you ensure that transactions are tagged, reported or blocked as they should be in the network? Example: A cross-border transaction was sent across banks using the text “Charles Taylor – Nuclear bomb”. Even though the transaction was blocked, the investigation was started, and a message was sent to the counter bank. A second investigation procedure was initiated. Is this how you would like this to work?
5. The delivered performance vs as experienced by the customer
How do you know that the performance your measure is the same as the performance your customer is experiencing? Example: all monitoring systems are green, and the customer sent his transaction before the cut-off. However, the transactions are processed the next day.
Conclusion
The mentioned examples all went through sound inside-out QA procedures. However, they lead to issues in production. Preventing these issues from happening is a balancing act. The questions to be answered are:
- What is the impact of these risks?
- Is there a way to mitigate them?
- Do the costs outweigh the potential damage?
From a WTSS perspective, it is challenging to give un-opinionated advice. This is our business, after all. However, we see the damage it does to the credibility of a bank’s transaction service.
However, we can draw an objective conclusion: affordable solutions are available to mitigate these risks. WTSS is providing one of them 😉
