The challenge

The banking core held the institution's essential data and operations, and there was no intention of replacing it: it did what it had to do. The problem was a different one. Every new channel integrated against it from scratch.

The team building an application had to learn the banking system's own formats, interpret its response codes and solve validation, error handling and operation tracking on its own. A change in the core forced a review of several consumers at once. A new application rebuilt integrations that already existed in another project, with different criteria.

The most delicate point appeared when an operation did not end with an immediate response. After a connection drop or a timeout, the channel was left without certainty: it did not know whether the request had been rejected, was still in progress, or had been recorded correctly by the core. In a financial environment, repeating an operation without knowing its state is as risky as losing it.

The solution

We built an integration layer between the core and the systems that need to query or record banking information. It works as a stable boundary: channels consume service contracts defined per operation, and specialized adapters translate those requests into the format the core expects.

Six channels are enabled: online banking web, online banking mobile, the branch back office, the call centre, internal systems and third-party integrations. The journey starts when a user initiates a query from any of them. The application sends the request to the service layer, which validates identity, permissions and the presence of mandatory data before touching anything. If the request is valid, the corresponding service applies the integration rules and hands it to the adapter.

The layer publishes twelve operations grouped into four families. Position: balance query, movement query, customer accounts query and receipt query. Transfers: new transfer, status query and operation reversal. Payments: new bill payment and payment query. Products: term deposit query, new term deposit and loan query. Each one has its own contract, version and execution mode, synchronous or deferred.

The adapter transforms the message without exposing that complexity to the channel: it converts fields, codes and structures into the core's model, executes the communication and receives the result. It then normalizes the response, so consuming applications always work with the same contract, regardless of how the core represents the information internally.

When the operation completes successfully, the channel receives a functional response it can show the user. When it is interrupted, the integration keeps the identifier and the state of the exchange. Instead of blindly repeating the request, the support team checks which stage it reached and verifies the result against the core before deciding whether a retry is warranted.

Every operation is tied to a correlation identifier. From the tracking view, the authorized team can check the reception time, the originating channel, the invoked service, the state and the technical result. Sensitive data is protected: the trace exists to diagnose an incident, not to become a parallel copy of banking information.

This design also changes how a channel is added. The team building an application does not implement communication with the core again: it consumes the services already published and focuses on the experience and the rules of its own product. If the core changes, the adaptation is resolved in one place instead of in every consumer.

Platform architecture

The architecture separates five responsibilities: consuming channels, the access and security point, the integration services, the specific adapter and the core. That division is what prevents external contracts from reproducing the banking system's internal structures, which is exactly the coupling the project set out to remove.

Synchronous operations traverse the layer and return a normalized response to the channel. Those requiring deferred processing keep a queryable state and a unique identifier. Treating each interaction according to its real behaviour is what makes it possible to avoid indiscriminate automatic retries on financial operations.

Observability follows the whole journey. Technical events record the request's progress and make it possible to relate what happened in the channel with the actual invocation against the core. Support can investigate a single operation without walking through the isolated logs of four different systems.

The core remains the system responsible for processing and confirming banking operations. The layer does not duplicate that responsibility: it controls the exchange, translates the contracts and presents a stable interface for everything that evolves around it.

The implementation

We started by identifying the priority operations and documenting, for each one, its inputs, responses, validations and possible error states. Before adding the first channel we defined the integration contracts and built reproducible test cases, to confirm that the new layer interpreted the core exactly as the existing processes did.

The rollout was progressive, and that was the design decision that mattered most. Each operation was validated end to end before the next one was added: correct responses, functional rejections, timeouts and recovery from communication failures. That allowed the integration to evolve without demanding a core replacement or a simultaneous migration of every channel.

The result is an architecture where the core keeps its transactional role and new developments rely on a controlled, traceable interface. The institution adds services around the core without turning every digital initiative into an integration project that starts over.