Real-time cores and Finxact
Moving from a batch coreto a real-time core.
A real-time core posts transactions as they arrive, exposes its functions through APIs and publishes its changes as events. Moving to real-time from batch means planning for the payment rails, surrounding systems, and bank routines that still run on cutoffs, files, and business days. Ignite has partnered with several banks to implement Finxact, Fiserv's real-time core, and the same planning applies to any real-time core.
The advantages
What a real-time, API-first core changes.
Banks moving to a real-time core usually cite these six. We describe them as Finxact provides them; other real-time cores offer similar capabilities, implemented differently.
- 01Real-time balancesCustomer balances, holds and available funds update as each transaction posts, so customer-facing functions don't wait for an overnight run.
- 02Functions behind APIsDigital, branch and partner channels integrate with the core directly rather than through files and screens.
- 03Changes published as eventsThe warehouse, fraud monitoring and alerts follow the core as it changes, instead of a day later.
- 04Products built by configurationProducts are assembled from components, fee plans and rate matrices, so new products can launch one at a time.
- 05An extensible data modelThe bank adds its own fields and rules through an extension framework, without changing the vendor's code.
- 06Point-in-time historyRecords can be read as of any past moment, for audit, investigation and reconciliation.
From Fiserv's Core Innovation with Finxact and its 2024 overview, and our own work with the platform.
Batch and real time
A real-time core still runs on a business calendar.
Posting happens as items arrive, but interest still accrues daily, end-of-day balances are still computed and the general ledger still closes each business date.
| A batch core | A real-time core | |
|---|---|---|
| Posting | Overnight, in an order the bank sets | As each item arrives |
| Balances | Last night's, plus memo posts | Updated as each item posts |
| Overdraft decisions | In posting order, at night | Item by item, as they come |
| The day | Ends with the batch run | A business calendar, with daily accruals and end-of-day balances but no posting window |
| Integration | Files and screens | APIs and events, with files where a rail or vendor needs them |
| Product change | Code and releases | Configuration |
| Data | Overnight extracts | Events as they happen, extracts to prove them |
| Hosting | A data center, the bank's or a processor's | The vendor's cloud, with the cloud provider as a fourth party |
Payment rails
FedACH and Fedwire still settle in windows.
A payment can post in real time and still settle in a window. For each rail, the bank decides its accounting day, how effective dates are set, and how items in transit are handled over nights, weekends and holidays.
- 01ACHSame Day ACH settles at 1:00, 5:00 and 6:00 p.m. Eastern; next-day files settle at 8:30 a.m. Returns and notifications of change arrive as files.
- 02WiresFedwire Funds opens at 9:00 p.m. Eastern for the next business day and closes at 7:00 p.m., with customer transfers cut off at 6:45; it closes on weekends and holidays. Sunday-through-Friday operation is expected in 2028 or 2029.
- 03ChecksImage and on-us files exchanged on schedules, then posted to the core.
- 04Cards and bill paySettlement files from the card processor and the bill pay provider, on their calendars.
- 05RTP and FedNowThese run continuously. A real-time core removes the posting lag, but sending still needs screening, limits and liquidity around the clock. RTP and FedNow.
The Federal Reserve's FedACH processing schedule and Fedwire operating hours. Finxact offers an optional direct Federal Reserve connection for ACH and wires; some banks use their own connection or keep their payment hub instead, deciding rail by rail.
The considerations
What changes across the institution.
Products and operations
Posting order and overdraft
Deciding items as they arrive changes overdraft outcomes and fees. Revisit the policy, confirm opt-in handling, and test fees in a parallel run.
Holds
Authorization and deposit holds reduce the available balance as soon as they're placed, while the ledger balance is unchanged. Staff need to be able to explain the difference.
Interest and fees
Confirm day count, rounding and posting order in writing for the release you'll run, and run parallel across a month-end and a statement cycle.
Branch routines
Tellers need retraining on authorization, posting and balancing when the core posts immediately.
Finance and data
The general ledger
GL activity builds through the day and closes each business date, and the core sends a daily GL file to the bank's own general ledger. Reconcile to the core's trial balances and rehearse month-end and quarter-end.
Events and reports
Use the event stream to keep downstream systems current, and reconcile them against the core's reports.
Custom fields
Custom fields reach downstream systems through the APIs and the event stream; standard reports keep fixed layouts. Plan where each custom field needs to land.
Running two cores
A phased move runs both cores for a while, and reporting has to combine them.
Technology and risk
Integration patterns
Choose APIs, events or files for each connection. Events can arrive more than once, so consumers must handle duplicates.
Credentials and access
Keep secrets in a vault and rotate them, mask sensitive fields at the source, and map every role to its core permissions.
Cloud and third parties
Understand which controls sit with the vendor and which with its cloud provider, and get commitments on data return at exit and evidence of resilience. FFIEC on cloud.
Core contracts
In September 2026 the agencies said they'll weigh core providers' transparency, deconversion fees and limits on integration. The joint statement.
What stays batch
Systems that stay on files and schedules.
At one community bank on Finxact, more than a dozen daily report loaders feed the warehouse, and daily extracts feed AML monitoring. Each feed needs an owner and a decision to keep, rebuild or retire it.
Outside the core, still on schedules
- Statements, notices and print
- AML case management, and SAR and CTR filing
- CECL, asset-liability management and the bank's general ledger
- Loan origination and its regulatory reporting
- The data warehouse and the reports on it
What the core gives them
- End-of-day balances, daily accruals and general ledger journals by date
- Calendars for interest, maturity, statement and fee dates
- Dormancy and escheat statuses, with each state's escheat period set in the core and a file for the bank's escheatment vendor
- Year-end tax files for the bank's e-file partner, with a correction process for missed or wrong records
- Standard reports, and an event stream for everything else
How to move
Move in phases, and prove each one.
Banks that have moved went product by product or in waves, and their hardest problems were rarely technical.
Phase by product or segment
New products first and the rest later, or migrations in waves a year apart, each proven before the next.
Balance to zero
At every stage of the conversion, with no tolerance for differences in money. How we reconcile.
Field-by-field comparison
Compare the full population and each downstream file, field by field, against the old core's output.
Parallel runs
Run parallel through a month-end, a statement cycle and a delinquency roll before relying on the numbers.
Mocks and the dress rehearsal
Write exit criteria before each mock. Make no code changes between the final mock and the dress rehearsal, which runs on the conversion weekend's timing.
Regression testing
The vendor ships the core, and behavior can change with each release. Test the bank's paths every time.
New skills
API and event engineering, and vendor training for the teams who run the core day to day.
Day one and hypercare
Rules for the first day, and days to weeks of hypercare with the vendor at the table.
Change management
Tellers, operations and finance work differently afterward, and conversions succeed or fail on how well they're prepared. The core conversion guide.
Who runs on Finxact
Banks and fintechs running on Finxact.
Fiserv calls Finxact the number one next-generation core in the U.S. for clients in production, and its 2026 marketplace listing cites more than 35 institutions and 45 million live accounts. The institutions below have announced it publicly.
Fiserv's Core Innovation with Finxact; the count is from Finxact's own AWS Marketplace listing, 2026. Public announcements only; we don't name our own clients.
How Ignite supports you
We've partnered with several banks to implement Finxact.
The same planning and integration work applies to any real-time core, and we bring it to whichever core a bank chooses.
Readiness
We assess products, operations, finance, rails and surrounding systems for real time before the plan is set.
The ecosystem
We map each surrounding system to what works with the new core today. The Finxact ecosystem.
The integrations
We build and test the rails, data pipelines, monitoring feeds and reporting.
Spend 30 minutes with us
Talk with us about your move to a real-time core.
No pitch, no obligation. And if we're not the right team for it, we'll tell you that too.