As a payments, risk, or compliance leader at a regional or mid-size bank, you have probably lived some version of this conversation: FedNow is live, RTP volumes keep climbing, your core provider says you are connected or close to it, and someone on your board wants to know why the institution is not further along.
I spent an hour inside that exact question in June, on a PayCLT Innovation Talk panel at Fintech & Insurtech Generations 2026, part of Charlotte Fintech Week at UNC Charlotte Center City. The session was called "Real-Time Payments Need Real-Time Intelligence: Where AI Actually Fits." Dean Nolan of PayCLT moderated, and I shared the stage with Rich Dooley of The Clearing House and Vijay Vardhan of Finzly.
The conference theme was "From Hype to Reality," and that is a fair description of where the industry sits. FedNow launched in 2023, and in 2024 the RTP network moved 343 million payments worth $246 billion, up 38 percent year over year. The rails work. Yet adoption among community and mid-tier banks still lags well behind the infrastructure's availability. Here is the argument I kept coming back to, on stage and off: the rail is the necessary part. It is not the sufficient part. Everything hard about real-time payments lives in what has to happen at the speed of the rail.
A real-time payment differs from ACH or wire in two ways that matter more than anything else about it.
First, it is irreversible. An ACH payment has a return window. A wire has a recall process. A real-time payment, once settled, is gone. That single property moves AML screening, sanctions checks, and fraud detection out of the batch window and into the decision path, before settlement, in the seconds the rail gives you. If those checks cannot keep up, your customer never really gets a real-time payment, they get a delayed payment with real-time liability.
What breaks at batch speed: a sanctions check that takes 30 minutes, a fraud score computed overnight against yesterday's data, a KYC status last verified at onboarding.
What good looks like: screening that evaluates at submission, customer status that reflects a continuous recertification loop, and a deterministic hard stop the moment a check fails.
Second, the network never closes. There is no overnight batch window and no Monday morning queue. A transaction at 2:17 AM on a Sunday gets the same treatment as one at 11:43 AM on a Tuesday, or it does not get processed. You cannot patch that with a staffing model. Every control that still needs a person to queue and work it is now exposed around the clock, and a 24/7 rail wrapped in batch-era processes does not give you real-time payments. It gives you a 24/7 backlog.
The panel title asked where AI fits, and I think the honest answer has two parts:
The first is automation: workflows that remove human latency from repetitive decisions. Sanctions screening, consent verification, exception routing, dispute intake. This work is deterministic, auditable, and well understood, and most institutions have at least started it. It is table stakes.
The second is real-time decisioning: models that evaluate context at the moment of the transaction and render a judgment (a fraud score, a sanctions match probability, a risk signal) inside the window the rail allows, against live data rather than last night's file. Far fewer institutions have closed this gap, and it is where the differentiation lives. This second kind of work, not rail connectivity, is the real adoption problem.
ISO 20022 raises the stakes here in a way most teams underestimate. These are not just payment instructions anymore. The messages carry invoice data, remittance detail, and structured party identifiers. That structured data is the fuel for every model I just described. Institutions that treat ISO 20022 as a migration chore get the cost without the value. Institutions that treat it as a data play get the differentiation.
Regulation is pushing in exactly the direction the network already forced. FinCEN's proposed 2026 AML/CFT program rule points away from periodic, batch-based review and toward continuous transaction monitoring and a program that stays current as an institution's risk profile changes.
I read that as good news. The same continuous monitoring that satisfies an examiner is what enables real-time fraud detection and faster approvals for the customers you want to keep. Institutions that build it now will meet the next requirement with configuration changes. Institutions that wait will build it under regulatory pressure, on a timeline they do not control.
Speed of settlement is the price of admission. Speed of safe, compliant settlement is the competitive position.
Macedon has been building in financial services for 17 years, so we tend to see exactly where these programs stall. The institutions moving fastest on real-time payments are not the ones that connected to a rail first. They are the ones that treated the decisioning and compliance infrastructure around the rail as the actual project.
For one lending client, we wired OFAC sanctions and consent checks directly into the decision path instead of bolting them on afterward, and that change took roughly 25 auditor-hours a day out of the process.
The same pattern holds for KYC: recertification that runs continuously between cycles rather than annually, so a customer's status is current at the moment a payment needs an answer.
None of this is glamorous. It is the difference between a real-time program that works and one that is technically on the network and operationally stuck.
If you want to see how this looks in production, we have written up several of these builds in our financial services case studies, or you can continue reading on Appian Connected KYC.
If you are working through where these checks should sit in your transaction flow, or weighing build versus buy for the intelligence around the rail, I am glad to compare notes on what we have seen work. Grab time on my calendar: https://meetings.hubspot.com/john-espey