.png){kind=logo}
A card is tapped at a till. Somewhere in the fraction of a second before the terminal prints "approved," something has to decide whether that payment is genuine. Nobody at the counter is waiting on a human reviewer. What they are waiting on is a chain of software that has to gather what is known about the card, the account and the behaviour behind it, score the risk, and return an answer before the payment network gives up waiting.
For most of the industry's history, that decision arrived too late to matter. Fraud analysis ran overnight, in batches, after money had already moved. Institutions found out the next morning. Recovery meant weeks of chargebacks. The economics of that model have quietly collapsed. Payments got faster, fraud got faster, and the window in which a bad transaction can still be stopped shrank to something measured in milliseconds.
Gowtham Reddy Pappula has spent his career inside that window. A senior data engineer working with large financial and insurance data operations, he rebuilds the pipelines that carry transaction data to the risk models, and his argument is that the models themselves are rarely the bottleneck.
"The true bottleneck in real-time fraud decisioning is rarely the machine learning model itself," he says. "It is the speed at which historical and contextual data features can be piped to the model."
That distinction matters more than it sounds. A fraud model needs context to be useful. It needs to know what this account normally does, where it normally does it, and how the current request compares. Assembling that context is a data engineering problem, not a data science one. It is where the time goes.
Pappula's response was to stop treating the pipeline as a delivery mechanism and start treating it as part of the decision. He re-architected batch-oriented workflows into event-driven streaming, moved model scoring away from direct database reads, and put frequently needed context into fast in-memory stores so it could be retrieved without a round trip to slower systems. By his account, end-to-end processing fell from around three minutes to under two hundred milliseconds, which is the difference between analysing a fraud case and preventing one.
The numbers he reports from that work are the kind that only show up once a system is genuinely in production. Pipelines handling more than ten million events a day. Uptime in the region of four nines. A reduction of roughly a third in false positives, which sounds like a technical footnote and is in fact a customer experience problem, because every false positive is a legitimate cardholder standing in a shop being told no.
Reliability turned out to be inseparable from the fraud question. A risk model fed corrupted or incomplete data does not fail loudly. It fails quietly, and keeps returning answers that look plausible. Pappula built an observability layer to catch exactly that, with automated lineage tracking and circuit breakers that isolate suspect data before it reaches the scoring engine. He reports that the time taken to detect a pipeline failure dropped from hours to under two minutes.
"High-throughput streaming pipelines fail quietly if observability isn't built into the data layer itself," he says. "Pipelines need automated circuit breakers and schema-enforcement filters that quarantine corrupted or anomalous data payloads without halting real-time streaming operations."
That framework became the basis of a paper accepted in a peer-reviewed journal, on monitoring large-scale data pipelines and recovering from failures. It is a subject he has since carried to other audiences, speaking on pipeline observability and operational automation at the Codorra 2026 global conference and judging engineering and cloud entries at NexusHacks 2026. He reviews research in the same territory as an IEEE peer reviewer, assessing work on real-time streaming and distributed systems.
The broader shift he describes is one the payments industry is still working through. Detection after settlement is becoming a legacy posture, useful for reporting and increasingly useless for prevention. What replaces it is an architecture where risk is computed before authorisation, which puts an unusual amount of weight on infrastructure that most people never see and few outside the field think of as interesting.
Pappula is fairly direct about where that leaves organisations still running the old model. Batch pipelines, in his view, are not simply slower. They are structurally incapable of the thing the business now needs, which is an answer while the transaction is still in flight.
It is an unglamorous position to hold. The work does not produce a visible product, and when it goes well nothing happens at all, which is precisely the point. A fraud case that never becomes a case leaves no trace, no chargeback, no investigation and no customer complaint. The measure of the system is an absence, and building for an absence takes a particular kind of engineer.
