TL;DR: Batch-based AML monitoring was built for a world where payments settled overnight. With FedNow processing $245 billion in Q2 2025 and transaction volume growing 645% year-over-year, compliance teams need systems that evaluate risk before settlement, not after. We built Sphinx's real-time monitoring layer to score transactions in milliseconds, reduce false positives by 87%, and keep every decision auditable.
Batch Processing Was Built for a Different Payment System
For most of AML's history, batch processing made sense. Payments moved slowly. Wire transfers took hours. ACH settled overnight. Compliance teams could collect a day's transactions, run them through rule-based engines after close of business, and review the output the next morning. The lag between transaction and review was acceptable because the lag between initiation and settlement was just as long.
That architecture no longer holds.
FedNow now connects over 1,500 financial institutions across all 50 states. When the Federal Reserve raised the transaction limit from $1 million to $10 million in late 2025, instant payments shifted from a retail convenience to a corporate treasury rail. High-value transfers that once gave compliance teams until end of day for review now settle in seconds and are typically irreversible. A batch job that runs at midnight cannot catch a suspicious $8 million transfer that cleared at 2:14 PM.
The EU's Instant Payments Regulation compounds this pressure, requiring euro transactions to complete within 10 seconds while maintaining effective AML and sanctions controls. Regulators on both sides of the Atlantic are converging on the same expectation: if the payment is real-time, the compliance check must be too.
Why Rules Engines Break Under Real-Time Pressure
Moving from batch to real-time is not just a scheduling change. Traditional rule-based monitoring systems were designed to process transactions in bulk, applying static thresholds across an accumulated dataset. A rule might flag any international transfer over $10,000, or any series of transactions that exceeds a velocity threshold within a 24-hour window. These rules work well enough when you have the full day's data in front of you.
In a streaming environment, each transaction arrives independently. The system has milliseconds to evaluate it against customer history, peer group behavior, sanctions lists, and risk typologies, then return a decision before settlement. Rules engines struggle here for three reasons.
First, static thresholds generate noise at scale. Industry research consistently shows that roughly 95% of AML alerts from traditional systems are false positives. At batch-processing volume, that noise is manageable. At real-time volume, it buries analysts.
Second, rules cannot adapt to context without manual reconfiguration. A $9,500 transfer from a long-standing business customer with consistent patterns is not the same risk event as a $9,500 transfer from a newly onboarded individual in a high-risk jurisdiction. Rules treat them identically unless someone writes and maintains a rule for every permutation.
Third, batch systems have no mechanism for pre-settlement intervention. They can flag a suspicious transaction after it has already cleared. In the world of instant payments, that means the money is gone before the alert is generated.
How Our Agents Monitor Transactions in Real Time
We built Sphinx's transaction monitoring to operate as a streaming system, not a batch queue. Every transaction is evaluated as it occurs, scored against multiple risk dimensions simultaneously, and resolved to an accept, escalate, or hold decision before settlement completes.
The architecture follows the same Interpretable Agentic Framework that governs all Sphinx workflows. Three specialized agents evaluate each transaction from different angles. The Prosecutor identifies risk indicators: sanctions proximity, unusual velocity, geographic anomalies, structuring patterns. The Defender interrogates those signals, checking for mitigating context like established customer behavior, known counterparties, or business-consistent transaction patterns. The Judge arbitrates between the two positions using a versioned decision rubric and returns a structured recommendation.
This happens in milliseconds. The system does not queue transactions for later review. It does not rely on static thresholds. Each decision draws on the customer's full behavioral profile, the institution's risk appetite configuration, and current sanctions and watchlist data.
ISO 20022 messaging, which FedNow and the EU's instant payment rails both use, provides significantly richer transaction data than legacy formats. Structured fields for sender identity, recipient information, and payment purpose give our agents more signal to work with. We ingest and parse these fields natively rather than treating them as unstructured text, which improves both accuracy and the quality of the audit trail.
Every decision is logged with the full reasoning chain: what each agent observed, what evidence it weighed, and why the final recommendation was reached. This is not a risk score with a confidence interval. It is a structured narrative that an analyst or examiner can read, challenge, and verify.
Where Real-Time Monitoring Still Needs Humans
We are direct about what real-time automated monitoring cannot do.
Complex layering schemes that unfold over weeks or months across multiple institutions are not reliably detectable at the individual transaction level. Our agents flag components of these patterns, such as rapid movement through multiple accounts, but the full picture often requires an analyst who can synthesize information across time horizons and data sources that no single transaction contains.
Novel typologies present a similar challenge. Our system learns from historical patterns and adapts through versioned Gene updates, but genuinely new money laundering methods, ones that do not resemble any known pattern, may pass initial automated review. We design for this by routing low-confidence decisions to human analysts and feeding their judgments back into the system as structured training signals.
Trade-based money laundering, where value is moved through the over- or under-invoicing of goods, often requires domain expertise and document review that extends well beyond transaction data. Our agents can flag pricing anomalies against commodity benchmarks, but the final determination frequently depends on a compliance officer who understands the specific trade corridor.
Pre-settlement holds also create friction. When our system places a hold on a transaction pending review, the customer experiences a delay. For legitimate high-value instant payments, that delay can have real business consequences. We work with each institution to calibrate hold thresholds so that the compliance benefit justifies the customer impact, but this is an ongoing tension, not a solved problem.
What Changes in Production
The shift from batch to real-time monitoring changes the compliance function in ways that extend beyond alert timing.
Analysts stop spending their mornings triaging overnight alert queues. Instead, they receive a curated stream of escalations that have already been pre-investigated by our agents, with the reasoning documented and the supporting evidence assembled. Review time per case drops substantially because the analyst is evaluating a structured recommendation rather than starting from raw data.
False positive rates drop because the system evaluates each transaction against dynamic, contextual baselines rather than static rules. Across our customer base, we see an 87% reduction in false positives compared to the legacy rule-based systems our agents replace. That is not because the rules were poorly written. It is because rules, by design, cannot incorporate the kind of contextual reasoning that streaming agent-based monitoring provides.
Regulatory risk decreases because pre-settlement monitoring means suspicious transactions can be held before funds move, not just flagged after the fact. For institutions operating on FedNow or other instant rails, this is the difference between preventing a suspicious transfer and filing a SAR about one that already cleared.
One customer, an institution processing high volumes of instant payments, reduced alert disposition time by 99% after deploying Sphinx's real-time monitoring agents. Their six-month backlog cleared in two days. These results reflect what happens when monitoring moves from a batch afterthought to a streaming-first architecture.
The Regulatory Direction Is Clear
FinCEN's modernization proposals emphasize real-time transaction monitoring and AI-based risk assessment as core expectations for compliant institutions. The language around "reasonably designed" monitoring programs is increasingly interpreted to mean pre-settlement checks for instant payment rails. A batch system that reviews transactions hours after settlement is difficult to defend as reasonably designed when the payment infrastructure itself operates in real time.
FATF's guidance reinforces this direction. Recommendation 10 and its interpretive notes stress that monitoring effectiveness depends on upstream controls: accurate onboarding data, strong identity verification, and ongoing customer risk assessment. Real-time monitoring that draws on these upstream signals in the moment of transaction evaluation, rather than retroactively in a batch review, aligns more directly with FATF's intent.
The question for compliance teams is no longer whether to move beyond batch processing. It is how quickly they can get there without compromising the auditability and explainability that regulators require. That is exactly the problem we built Sphinx to solve.
Frequently Asked Questions
What is real-time AML transaction monitoring?
Real-time AML transaction monitoring evaluates every financial transaction as it occurs, scoring it for money laundering risk and returning an accept, escalate, or hold decision before the payment settles. Unlike batch processing, which reviews accumulated transactions after the fact, real-time monitoring operates continuously and can intervene before suspicious funds move.
Why can't batch processing handle instant payments?
Instant payment rails like FedNow settle transactions in seconds, and most are irreversible once completed. Batch processing reviews transactions hours after settlement, which means suspicious activity is only identified after the money has already moved. For a payment system designed around speed and finality, post-settlement detection is functionally too late.
How does Sphinx reduce false positives in real-time monitoring?
Sphinx uses three specialized agents, the Prosecutor, Defender, and Judge, to evaluate each transaction from multiple perspectives. Rather than applying static rules that flag every transaction crossing a threshold, the agents assess contextual factors like customer history, counterparty relationships, and behavioral baselines. This approach reduces false positives by 87% compared to traditional rule-based systems.
Does real-time monitoring replace human compliance analysts?
No. Real-time monitoring handles high-volume, pattern-recognizable activity, but complex investigations, novel typologies, and trade-based money laundering still require human judgment. Sphinx routes low-confidence decisions to analysts and treats their feedback as structured training signals to improve future performance.
What regulations require real-time transaction monitoring?
The EU's Instant Payments Regulation requires AML and sanctions controls that operate within the 10-second settlement window. In the United States, FinCEN's modernization proposals increasingly interpret "reasonably designed" monitoring programs to mean pre-settlement checks for instant payment rails. FATF Recommendation 10 emphasizes ongoing monitoring as part of customer due diligence obligations.
.png)
