How We Built Real-Time Transaction Handling

Banks rely on their deposit network to track customers’ transactions and interest accurately, which makes the way a network books each transaction highly consequential. When a customer’s funds are swept on Tuesday, they should earn interest on Tuesday, and the network’s records should match the bank’s. That sounds like a given, but in many networks it isn’t, and the gap costs depositors interest and banks time. We built Real-Time Transaction Handling to close it.

How deposits move today

Most banks sweep funds between an operating account and a deposit network on a daily cycle. The bank’s core runs the sweep, then accrues interest on the end-of-day balance. Because the swept funds are already out of the operating account by then, the core isn’t paying on them.

The network side usually works differently. The bank sends a file, the network picks it up, and the transaction is recorded on the day the file is processed, typically the next business day.

On a sweep day, that leaves a gap:

• The funds have left the operating account, so they no longer earn there.
• The network hasn’t recorded them yet, so they haven’t started earning there.
• The depositor’s money spends a day earning no interest.

It’s easy to dismiss one day as a wash, but this gap repeats on every sweep, for every depositor.

What we set out to fix

We kept hearing similar pain points across our member banks and their core partners. They became our goals.

• Full interest on every sweep. A depositor’s funds should earn interest on the day they move.
• Records that match the core. When the core and the network show different dates for the same sweep, teams reconcile by hand. We wanted both ledgers to show the same date.
• Minimal lift for the bank. Any fix that required a bank to change its own daily process was a non-starter. Once set up, whatever we built had to fit the process the bank already runs.

How we built it

The idea is simple: record each sweep on the date it actually happened on the bank’s core, not on the date we happened to process the file.

1. 1The core sends the on-core date. The bank’s file arrives on its usual schedule, carrying the date of the transaction on the core.
2. 2We post to that date. NBID records the transaction as of the on-core date, so both ledgers show the same date.
3. 3Interest catches up automatically. Our systems pick up the incremental interest from the date adjustment and include it in the next day’s postings, so depositors get every day of interest they earned.

The hard part about dating a transaction backward is doing it without breaking either side’s books. Many legacy networks post on the processing date instead, because backdating can create reconciliation breaks and operational overhead.

We designed our ledger and interest processing so the difference is absorbed cleanly, and so statements and reports mirror what the bank sees on its core. Sweeps run on the same schedule and cut-off times and file timing stay the same.

Why one day adds up

In the last year, a net of $112 million has been added into reciprocal deposit products every day. Earning 3% interest, that is $9,200 of missed interest every day, and $3.4 million of missed interest annually.*

*Reciprocal deposits at FDIC-insured institutions grew from $422 billion at March 31, 2025 to $462.8 billion at March 31, 2026, per call report data cited by the Federal Reserve Bank of Dallas and the FDIC. Net growth of $40.8 billion divided by 365 days; one day of interest at 3.00% on a 365-day basis (9,188 per day, $3.35 million per year). Illustrative; rates vary by institution and are subject to change.

Availability

Real-time transaction handling is already live for pilot banks and on by default for banks on certain core integrations. For some cores, it is a simple configuration change that the bank and NBID make together.

To get started, member banks should reach out to their Regional Director.