One of our customer which is on the Top 5 biggest bank in Indonesia has a classic challenge. When a bank user complain about their services or encounter a problem using their services, how can they quickly pin point what is the issue if there is an actual issue, or if service disruption is caused by external factor beyond the bank’s control?
The acquiring business of the Bank is specifically find this challenging. They deploy Electronic Data Capture (EDC) devices to the merchants, where that merchant’s customer can transact using Card Payment, QRIS, NFC, other payment methods, when something doesn’t work there are so many point of failures that requires different stack of technologies old and new.
The most common issues they are facing are: (sorted from user facing to the back end)
- EDC devices problem
- Connectivity from Cell Provider
- External facing Firewall & Router
- NAC (Network Access Control) for the EDC
- TLE where encryption/decryption happens
- Middleware
- Legacy Core banking system (for on Bank transaction)
- Switching system (for off Bank transaction)
Those are the technology stack, they also need to know if the issue is on the business stack such as and not limited to:
- Wrong PIN
- Not enough balance
- Rejection from certain payment network
- Switching Errors
To be able to have this complete visibility the solution need to be able to process all the data from the technology stack and the business stack.
Our Solution
We use Splunk to ingest all the logs and events from EDC, Cell Provider SLA, NAC, TLE, Legacy System and switching. Now looking for all the issues here are quite straight forward once you know your way around Splunk.
The next challenge is the business stack, since EDC and Financial Switching using ISO 8583 messages to communicate, we need to be able to decode the ISO 8583 messages. While the framework for ISO 8583 is published, the actual implementation between 2 entities are usually heavily customized for their business need. Whoever designed the messaging has probably left the company or don’t remember the detail, and for many cases the documentation is either outdated or incomplete. So we had to reverser engineer a lot of ISO 8583 messages format.
Once we are able to decode all that, putting all the data from both stack into a data model that the Bank can use easily is the next step. Our solution was flexible enough that 4 years after implementation, the Bank still relies on it heavily, they have the capability to use pivot to create their own reporting and dashboard at will.