Catching Stuck Transactions Before Clients Do
Category
Financial Operations & Automation
/
/
At Rail, a payment infrastructure handling thousands of transactions every day across deposits, withdrawals, exchanges, inter-custodial transfers, and internal journal entries, transactions would sometimes get stuck at various stages. Detection was entirely reactive: the team usually found out when a client escalated, and at times when senior management spotted something in the ledger. I built the system that made detection proactive and instant.
The challenge
The data existed, but it was hard to use. There was no way to filter for pending transactions in one go, so finding stuck ones meant going through the ledger status by status, since a transaction could be held under any of several. Even then, the reason it was stuck and whether it had breached its rail's SLA were not easy to see, and someone had to keep checking throughout the day.
There was no reliable way to catch stuck transactions: some surfaced as client ticket escalations in the CRM, others surfaced in meetings between clients and the client success team, and at times senior management spotted them while looking at the ledger for other reasons.
Without an easy way to see the reason a transaction was stuck or its SLA status, the team was effectively reacting case by case.
By the time anyone noticed, the transaction had often been stuck for a while. With no shared view, the same issue was sometimes investigated by more than one person, and resolving it meant chasing context across teams before anyone could act.
The approach
I built an end-to-end visibility and alerting system, deliberately using simple, low-cost tools the team could actually run.
Understood the system: worked with engineering on the transaction flow and database logic, and with financial operations to map the raw status codes into meaningful categories.
Built a real-time Superset dashboard that brought every transaction type into one view, showing client, custodian, status, how long each had been pending, and whether it had breached its rail's SLA.
Added a SQL layer that classified why each transaction was stuck (an inter-custodial transfer, a compliance alert, or an engineering failure), surfacing the root cause automatically.
Separated transactions that were progressing on their own from those that needed a human, so attention went only where it mattered.
Built the alerting: Superset data synced to a Google Sheet where a Google Apps Script using the Slack API ran every 10 minutes, notifying the operations team of pending transactions and the reason each was stuck.
The impact
With detection moving from a manual ledger check to an automatic scan every 10 minutes, the average processing time of stuck transactions dropped to about a fifth of what it was.
The team caught stuck transactions in near real time, often before a client noticed, instead of waiting for an escalation.
No one had to comb the ledger anymore. The alerts surfaced what needed attention.
Senior leadership was no longer pulled into daily transaction troubleshooting.
Every team worked from one source of truth, with the reason and SLA status visible at a glance, so escalations and duplicated effort dropped.
Clients received faster, clearer updates, and communication shifted from reacting to problems to getting ahead of them.
From reactive firefighting to proactive control
An end-to-end visibility and automation system turned Rail's financial operations from a reactive workflow into a proactive, data-informed process, cutting the time to clear a stuck transaction to about a fifth while improving cross-team collaboration and the client experience.
