Core Banking Integration: The Blackout Window Nobody Scopes

A customer pressed send on a transfer at 11:04pm and got an error. The same request at 6:15am the next morning worked perfectly. Nothing in the application changed, nothing in the network changed, and the logs on the app side showed a clean rejection from a system that had been answering happily an hour earlier.

That is core banking integration meeting the end of day process, and it is the single most common surprise on these projects. Almost every article on this subject explains authentication and message formats. Very few mention that the system you are integrating with closes for several hours every night, and that this fact will shape your architecture more than any protocol decision you make.

What you are actually integrating with

A core banking system is the book of record. It holds accounts, balances, products and the postings that move money between them, and it is usually 15 to 30 years old in design lineage even when the deployment is recent.

The estate you are likely to meet: Oracle FLEXCUBE, Infosys Finacle, Temenos Transact, TCS BaNCS, Finastra, Intellect Design, Azentio iMAL and ICS BANKS at the traditional end, with Mambu, Thought Machine Vault and 10x Banking at the cloud-native end.

The two ends behave nothing alike, and the distinction that matters is not age. It is whether the core was designed around a batch cycle or around a continuous ledger. A batch-cycle core has an operating calendar. A continuous one mostly does not. Everything below applies most sharply to the first group, which is still where the large majority of retail balances sit.

The blackout window is the design constraint

Every batch-cycle core runs an end of day process, and most run a beginning of day one too. Interest accrues, standing instructions execute, statements generate, the accounting date rolls forward, and while that is happening the core rejects writes.

Windows vary. A small institution might close for 45 minutes. A large one with multiple entities and a heavy product catalogue can be unavailable for 3 hours or more, and month end and year end are longer again. Somebody will tell you the window is 90 minutes. Ask for the last 30 days of actual durations, because the stated window and the observed window are rarely the same number, and the tail matters more than the median when your product is the thing that goes dark.

Three consequences follow, and they are the whole design.

Your product cannot be synchronously coupled to the core. If a customer action requires a successful core write to return a response, your product is offline whenever the core is. Nobody accepts a banking app that stops working at 11pm. This is the constraint that most often arrives late, because a proof of concept built against a sandbox during office hours never encounters it, and the sandbox frequently has no EOD process at all.

You need a queue with a replay path. Accept the instruction, persist it as your own record with your own identifier, acknowledge to the customer with an honest status, and post to the core when it reopens. This is not a workaround. It is the correct architecture for a system with a scheduled outage.

You need to tell the customer the truth. A transfer accepted at 11:04pm and posted at 06:15am is not a failure, and it is not instant either. Products that pretend otherwise generate support tickets for years. Say pending, show the expected posting time, and update.

There is a design decision hiding in that third point. A queued instruction can be shown as pending, or it can be memo posted immediately so the customer's available balance drops at 11:04pm and the ledger catches up at 06:15am. The second is a better experience and a larger build, because it means you are now holding a view of money the core does not yet know about, with everything that implies for reconciliation. Pick deliberately rather than discovering which one you built.

The related trap is the accounting date. During and immediately around the window, the core's business date may differ from the wall clock. A transaction submitted at 00:30 might post to the previous business day or the next one depending on where the roll sits. Store both the posting date and the value date on every transaction from day one. Retrofitting that distinction after go live means reprocessing history, and history in a ledger is exactly what you cannot casually reprocess.

The protocol question, answered honestly

Vendor material implies a modern API sitting in front of every core. In practice:

Core	What you usually get
Oracle FLEXCUBE	SOAP gateways over JMS and MDB, plus a Java and EJB layer
Infosys Finacle	Finacle Integrator
TCS BaNCS	Web services
Older regional cores	A file drop on SFTP, processed on a schedule
Mambu, Thought Machine	Genuine REST and event streams

Where a traditional core offers REST, it is usually a wrapper somebody built, either the vendor's own API gateway product or an integration layer a previous programme left behind. That matters because a wrapper inherits every constraint of what it wraps, and it adds one of its own: it can be down while the core is up.

The practical advice is to find out who owns the wrapper before you design against it. A vendor-supported gateway with a support contract is a dependency you can plan around. An undocumented layer built by a contractor in 2019 is a risk with a friendly interface, and its behaviour under load is unknown to everyone currently employed.

None of this changes the amount of work much. The fintech cost model prices core integration surface at 150 to 400 hours precisely because SOAP over JMS, a file drop and a modern API differ less in effort than people expect. What differs is the failure modes, and those you handle in your own layer regardless.

Real time balance is two different numbers

Ask for a real time balance and you will get one of two answers depending on who you ask, and they are both correct.

The posted balance is what the ledger says after all completed postings. It is authoritative and it lags, because a card authorisation this afternoon may not post until tonight's batch.

The available balance is the posted balance adjusted for holds, authorisations and pending items, which is what the customer thinks of as their money.

Products that display the posted balance to customers generate complaints, because a card payment made 20 minutes ago is invisible. Products that compute available balance themselves without reconciling it against the core generate worse problems, because two systems now disagree about money.

Worth deciding early: which number appears where. Most products show available balance on the home screen and posted balance in the statement, and label neither. Labelling both, in the customer's language rather than in banking language, removes a large share of the support volume these products generate in their first year.

The workable pattern is memo posting: hold your own view of pending items with a defined lifetime, display posted plus memo as available, and clear each memo item when the corresponding posting appears from the core. Every memo item needs an expiry and a reconciliation path, for the same reason every reservation in a stock system does. An unexpired memo entry that never matched a posting is a phantom, and phantoms in a balance are considerably worse than phantoms in a warehouse.

Idempotency, reversals and the state machine

Money APIs that are not idempotent are the fastest way to a serious incident. A retried call double-debits, and afterwards nothing in the system proves which attempt was real.

Three requirements, none optional.

An idempotency key on every mutating call, generated by you, stored by you, honoured on retry. Network timeouts are guaranteed and a timeout tells you nothing about whether the far side succeeded.

An explicit state machine with terminal states. Accepted, queued, submitted, posted, failed, reversed. A transaction sitting in an ambiguous state after a timeout needs a defined query path to resolve it, and that path has to run without human intervention because it will fire at 3am.

Reversals as entries, never as edits. A running balance updated in place cannot represent a backdated correction or a disputed transaction. Post append-only double-entry records, derive balances from them, and record corrections as reversing entries with effective dates. The first serious dispute is when this stops being a design preference.

The exception catalogue belongs in the specification rather than in a later phase. Returns, reversals, insufficient funds, chargebacks and provisional credit all rewrite the data model if they arrive after launch, because the happy path was specified and the rest was assumed. Model the full set before the first transfer, and treat that catalogue as the requirement document it actually is. On the builds we have inherited, this omission is the single most expensive one to correct, because by then there is production data shaped by the wrong assumptions.

One detail that costs real money when missed: OMR, KWD and BHD carry ISO 4217 exponent 3, so a codebase assuming 2 minor units corrupts Gulf currency quietly and compounds the error through every downstream report. Hold the exponent in a data table, keep integer minor units end to end, and add a test that fails the build on a hardcoded 100.

Reconciliation decides who is right, so build it first

Reconciliation gets scheduled after launch on most programmes, and that is the wrong order. When your system and the core disagree, reconciliation is what decides which one is right. Without it you have two opinions and no mechanism.

Build three-way reconciliation before the first live transaction: your records, the core's postings, and the rail's settlement file. Run it daily from day one, produce an aged break queue with owners, and treat an unexplained break as an incident rather than a backlog item.

Teams that defer this reach month 3 with thousands of unmatched items, no aged queue, and no way to say which of the three sides is wrong. Rebuilding trust in a ledger after that point costs more than the reconciliation module would have.

Rails, certification calendars and regional reality

Connecting to the core is half the project. Moving money means a rail, and each rail carries a certification calendar that belongs on the project plan before the architecture diagram does.

In Oman that means RTGS, MPCSS, OmanNet and the Direct Debit System. In the UAE, Aani, UAEFTS, UAEDDS, Jaywan and the WPS payroll file. In Saudi Arabia, sarie, and mada over SPAN. In India, UPI, IMPS, NEFT, RTGS and NACH with e-mandate. Cross-border adds SWIFT through Alliance Access or Lite2, with mandatory annual attestation under the Customer Security Programme.

The certification calendar is a schedule cost before it is a money cost. A rail that certifies in windows will not move for your sprint plan, and a slipped certification slot can cost more calendar than the integration itself took to build. Get the dates before you commit to a launch date.

Sandbox availability deserves the same treatment. The 14 to 22 week phase one figure assumes credentials exist on day one, and on a meaningful share of projects they do not. Chasing sandbox access through a partner bank's operations team is not engineering work and cannot be accelerated by adding engineers, so it belongs on the critical path with a named owner rather than in a backlog.

One integration detail worth carrying: ISO 20022 party and remittance data is structured and rich, and squeezing it into 35-character legacy fields loses information permanently. If a downstream system truncates, the data is gone rather than shortened, and the compliance team finds out during an investigation.

What it costs, with the hours shown

Published rates, published hours, arithmetic you can argue with.

Component	Hours	Note
Core system integration surface	150 to 400	Protocol matters less than the failure modes
Queue, replay and blackout handling	120 to 260	The part this article is about
Double-entry ledger and posting engine	400 to 800	The highest-risk module on any of these builds
Payment rail integration, per rail	180 to 350	Returns and exceptions included
Reconciliation and break management	250 to 450	Three-way, daily, from day one
Back office console with audit log	300 to 550	The module most often left out of quotes

The fintech control core, meaning the smallest thing that can move money and prove it afterwards, comes to 1,380 hours at the floor: onboarding 250, ledger 400, one rail 180, reconciliation 250, back office 300. QA and partner certification at 15 to 25 percent lifts that to about 1,587. At the ceiling the same 5 modules reach 3,250 hours, so the band is $95,000 to $227,500 at a $60 to $70 blend, with rates running $40 to $100 per hour by role.

Phase one runs 14 to 22 weeks from a signed integration register to a penny test on one live rail, and that assumes sandbox credentials exist on day one. Where they do not, the clock starts when they arrive rather than when the contract is signed.

A sequence that survives contact with the core

Before anything, get the operating calendar. Actual EOD and BOD durations for the last 30 days, month end and year end behaviour, and who to call when the window overruns.

Then the integration register. Every message, both directions, with its protocol, its owner and its test environment. Signed by someone at the bank. This document is the project.

Then the ledger, before any rail. Append-only, double-entry, with posting and value dates and reversal semantics. Everything else posts into it.

Then one rail, end to end, to a penny test. Resist the second rail until the first has moved real money and reconciled.

Reconciliation in parallel, not after. It has to exist before the first live transaction, which means it is built alongside the rail rather than behind it.

The question to ask the core team on day one is not which protocol they support. It is: what is your end of day window, how often does it overrun, and what happens to a request that arrives while it is running. The answer to that shapes everything you build afterwards.