Short answer
Real-time payments settle in seconds, around the clock, and are final and irrevocable once they clear. That is the point of the rails, and it is also the problem for anyone checking fees. Fee verification at most companies is retrospective. Reconciliation runs monthly or quarterly, which means a wrong charge is found weeks after the money has already settled and finalized, with recovery no longer in your control. On instant rails, the practical window to catch and recover a fee error shrinks toward zero. The fix is to verify at the speed the money moves, before the books close.
Here is the window, by rail.
| Rail | Settlement | Final once settled? | Window to catch a fee error before the money is gone |
|---|---|---|---|
| ACH (batch) | business days | no, defined return windows apply | a few days |
| RTP | seconds, 24/7 | final and irrevocable | effectively none |
| FedNow | seconds, 24/7 | final and irrevocable | effectively none |
| SEPA Instant | under ten seconds | final and irrevocable | effectively none |
The rails got faster. The audit did not.
What real-time payments actually are
Real-time payments are credit transfers that make funds available in the recipient's account within seconds, available every hour of every day of the year. In the US, two networks carry them: the RTP network, run by The Clearing House and live since 2017, and the FedNow Service, launched by the Federal Reserve in July 2023. Europe has the same thing in SEPA Instant Credit Transfer, which moves funds in under ten seconds. India runs the largest instant network of all in UPI.
The shared design goal is speed with certainty. A recipient gets the money immediately and can rely on it, because the payment is final. That certainty is exactly what makes these rails useful, and it is worth understanding what it costs on the fee side.
The two facts that close the window
Two properties of instant rails, taken together, are what compress the window.
The first is speed. These payments clear and settle individually, in real time, at any hour. There is no overnight batch, no cut-off, no settlement lag during which something can be paused and reviewed. The money is available to the recipient the moment the payment clears.
The second is finality. On the RTP network, a sending institution cannot revoke or recall a payment once it has been submitted. Settlement is final and irrevocable, and the network is strictly credit push, which means the payer instructs the payment out and there is no mechanism to pull it back. FedNow settlement is final in the same way. That finality is the point of the design. It is why a recipient can trust the funds instantly.
Put speed and finality together and you get a payment that has moved, settled, and become permanent before anyone has looked at whether the fee attached to it was correct.
Finality, precisely
It is worth being exact here, because finality is easy to overstate. Final and irrevocable does not mean the money can never come back under any circumstances. The RTP network provides a formal request-for-return-of-funds message, so a bank can ask the receiving bank to send funds back.
What it does not provide is a right to that return. The receiving institution is not obligated to return the money. It only has to respond to the request. So recovery on an instant rail depends on the counterparty choosing to cooperate, rather than on any ability of yours to reverse the payment. That is a very different position from a rail with a defined return window, where the reversal is a procedure rather than a favor.
For a fee error, that distinction is the whole story. If a provider charged you the wrong rate on a transaction that settled instantly and finally, you no longer control whether you get it back. You are left asking the counterparty to cooperate.
Your audit runs on the wrong clock
Now look at how fees actually get checked. Payment reconciliation is usually performed on a regular basis, monthly or quarterly, by comparing recorded transactions against bank and ledger records after the period closes. It is retrospective by design. You gather a period of activity, then you check it.
That cadence was built for a world where money moved on a delay. When settlement took days and returns had windows, a monthly review still landed inside the time you had to act. On instant rails, the same monthly review lands weeks after every transaction in it has already settled and become final. The audit is not wrong. It is running on the wrong clock.
The rails are explicit about their own economics, which makes the point concrete. The FedNow Service charges a fee of $0.045 per credit transfer, paid by the sender, and $0.01 for a request-for-payment message. The RTP network publishes the same per-transaction figures. Those are small numbers, and they are exactly the kind of per-transaction charge that a monthly audit reviews long after the fact. A rate that drifts from the contract, a markup applied where it should not be, a fee charged twice: on an instant rail, each one settles finally at the moment it is incurred, and your first chance to see it arrives at the end of the period.
Verification has to move to settlement speed
If the money now moves in real time and cannot be recalled, the check on what it costs has to move too. The old model, review a period after it closes and dispute what looks wrong, still works for slow rails with return windows. It does not fit a rail where the transaction is permanent before the review even begins.
The alternative is to verify at the speed the money moves. That means reconstructing the expected charge for every transaction from the contract as it happens, comparing it to what was actually charged, and flagging the discrepancy while there is still a counterparty conversation to have, rather than a quarter later when the trail is cold. It turns fee checking from a periodic audit into a continuous control.
That is the job Bluefyn is built for. Bluefyn verifies that providers charge exactly what they agreed to charge, reconstructing contract pricing and checking fees transaction by transaction. It analyzes transaction and provider data. It never moves, holds, or custodies funds.
Real-time payments made settlement instant and final. They did not make fee errors go away. They just took away the weeks you used to have to catch one. On these rails, the only verification that helps is the kind that keeps up.
Frequently asked questions
How long do you have to catch a fee error on an instant payment?
In practical terms, almost no time. Real-time payments on RTP and FedNow settle in seconds and are final and irrevocable, so the transaction is permanent before a monthly or quarterly reconciliation ever looks at it. The error is found weeks after the money has already settled, unless you verify the charge as it happens.
Can an RTP or FedNow payment be reversed if the fee was wrong?
Not by the sender. On the RTP network a sending institution cannot revoke or recall a payment once submitted, and settlement is final and irrevocable. There is a request-for-return-of-funds message, but the receiving institution is not obligated to return the money, only to respond. Recovery depends on the counterparty cooperating, rather than on any right to reverse.
Why doesn't monthly reconciliation catch fee errors on real-time rails?
Because reconciliation is retrospective. It is usually run monthly or quarterly, comparing a closed period of activity against the records afterward. That cadence was built for rails that settled on a delay. On instant rails, every transaction in the review has already settled and become final by the time the review runs, so a discrepancy is discovered too late to act on cleanly.
How often should fee verification run on instant payment rails?
At the speed the payments settle. If money clears in seconds and cannot be recalled, a per-transaction check that reconstructs the expected charge from the contract as each payment happens is the only cadence that keeps pace. A periodic audit still helps for slower rails, but on instant rails it arrives after the window to act has closed.
Do real-time payments have fees?
Yes. The FedNow Service charges $0.045 per credit transfer to the sender and $0.01 per request-for-payment message, and the RTP network publishes the same per-transaction figures. Those are the network fees. Any provider markup or processing charge layered on top settles just as fast and just as finally, which is why verifying that those charges match the contract has to keep up with the rail.
