Core Banking Integration Patterns

A synchronous call is the simplest pattern, and it fits real-time payments where the caller needs an immediate answer. The payment hub calls the core banking service, which checks the balance, debits GBP 1,200, and returns a success or failure response within a second. The advantage is simplicity, because the caller knows the result before it proceeds. The disadvantage is coupling, because if the core system is slow or unavailable, the payment fails immediately. Synchronous calls therefore need short timeouts, circuit breakers that stop calling a sick service, and a fallback that queues the payment rather than losing it. Asynchronous messaging fits payments where the caller can continue without an immediate answer. The hub places a message on a queue, such as an instruction to debit EUR 2,000, and the core banking system picks it up when it is ready. The queue guarantees delivery, so the message is not lost if the core system restarts. The disadvantage is that the caller does not know the result straight away, so it must listen for a response message and handle the waiting state. This pattern works well for bulk payments and for end-of-day processing, where a delay of a few minutes is acceptable and the queue smooths out peaks. File-based integration is the oldest pattern, and it still handles the largest volumes in most banks. A payment system writes a file containing 100,000 instructions, each with an account number, an amount, and a value date, and the core system reads the file overnight. Files are simple, auditable, and easy to replay, which makes them ideal for salary payments and direct debits. The disadvantage is latency, because nothing happens until the file is processed, and a single bad record can reject the whole file if the validation is not designed carefully. Modern file integration therefore validates each record separately and reports errors per record. Database sharing is a pattern that should be used with great care, because it couples two systems at the lowest level. One system reads or writes directly to the tables owned by another system, which is fast but fragile. A change to a table structure breaks every system that reads it, and a bad write from one system can corrupt data owned by another. Banks that still use this pattern usually restrict it to read-only access through views, so the consuming system cannot change the data. The safer alternative is to expose the data through a service, which hides the table structure and enforces business rules before any change is made. The atomic debit is the rule that governs every core banking pattern, whatever the transport. A payment must debit the sender account and record the payment instruction as one unit, so that a crash cannot create one without the other. If the hub sends a payment to the scheme but the core debit fails, the payment must not proceed. If the core debit succeeds but the scheme rejects the payment, the debit must be reversed. This is why payment systems use transaction identifiers that link the core entry, the hub record, and the scheme message, so that reconciliation can find any break in the chain and repair it automatically.