Processing governmental orders across three countries

Problem

Banks receive legally binding orders from public authorities. An order can be an arrest, which requires the bank to block an account or a specific amount of funds, or a transfer of funds, which requires the bank to pay the seized amount to the issuing authority, typically a bailiff. Authorities also send requests to track accounts and to disclose customer information.

These orders are not optional and not forgiving. They must be executed correctly and on time, and the bank operates in three countries. Each country sends its orders differently and expects its responses in its own way, through its own registry. The e-Arrest platform processes thousands of these requests per day.

Constraints

• Legally mandated workflows. A wrong or late action is a legal problem, not just a bug.
• Three different protocols. Each country’s registry has its own way of sending requests and receiving responses.
• One core banking system. Whatever the country, the actions land in the same place: Flexcube.
• Not everything can be automated. Some scenarios need a person to process them. Bank operators handle those cases manually, while customer service staff need to see a customer’s arrest orders when that customer contacts them.

Architecture

e-Arrest is a Kafka-heavy, event-driven system. Its business logic runs through four main microservices, three registry connectors and one orchestrator, alongside supporting services outside the core flow.

Three registry connectors, each an anti-corruption layer. Every country has its own registry connector, a dedicated microservice that speaks that country’s registry protocol and format. It receives the country’s requests, translates them into common domain events, and publishes them to Kafka. Responses travel the same way in reverse: the outcome goes back through that country’s registry connector, which translates it into what its registry expects.

One orchestrator, the main service. It consumes the domain events from Kafka and executes the required action, and the action depends on the type of request the registry sent:

• Arrest requests block the required amount directly in Flexcube. The funds stay blocked, and nothing is paid out.
• Transfer-of-funds requests go one step further on flows where automatic payment is enabled. The amount is blocked in Flexcube and then passed to Tieto Payment Hub, which pays it to the issuing authority without manual intervention.

The orchestrator also handles account tracking and customer information requests against the same core.

On top of the platform sits the operator UI, a React and TypeScript application owned by my team. Not every scenario can be processed automatically, and those cases land with the bank operators who handle arrests. They use the UI to process them manually.

The micro-frontend for customer service

Separately, the bank runs a shared micro-frontend platform that hosts both its customer-facing internet banking and its internal staff applications. I owned the epic to build an e-Arrest micro-frontend embedded in the staff customer service application. When a customer contacts the bank, customer service staff see that customer’s arrest orders in one central place, next to the other micro-frontends they already use, instead of switching to another tool. I drove its delivery end to end with the Product Owner against agreed deadlines.

Key decisions

An anti-corruption layer per country

Each registry’s protocol is someone else’s model, and it can change for reasons the bank does not control. Letting those formats reach the orchestrator would couple the core execution logic to three external systems at once, so a change in one country’s format would put every country at risk. A dedicated registry connector per country keeps each external model at the edge. The orchestrator only ever sees one domain language, so the logic that blocks and moves money exists once, and a new or changed country protocol is contained in its own connector.

Kafka between the connectors and the orchestrator

Putting Kafka between the registry connectors and the orchestrator decouples them in time and in deployment. A registry connector can accept an order even while the orchestrator is busy or being deployed, and the event waits durably until it is processed. Each side scales and ships independently, and the event stream is a record of every order that entered the system.

The right interface for each user

Operators and customer service staff need different things. Operators process the cases automation cannot, so they get a full application built for that work. Customer service staff only need to know an order exists and what it means for the customer in front of them, so they get a focused micro-frontend inside the tool they already use, rather than access to a separate application.

Results

• Transfer requests pay out automatically where automatic payment is enabled, from blocking the amount in Flexcube to paying the authority through Tieto Payment Hub, without manual steps.
• Three countries on one platform, each isolated behind its own anti-corruption layer, with a single orchestrator executing against the core.
• Customer service sees arrest orders in one central place, through the micro-frontend epic I owned, embedded in the bank’s shared platform.
• Full-stack ownership. I build features across the Spring Boot services and the React operator UI, from API design to delivery, and handle production issues in a system tied to legally mandated workflows.