Most loan modernisation programmes start from the process as it is documented: procedure manuals, BPMN diagrams from workshops and a target operating model. The trouble is that the documented process is rarely the one that actually runs. Over the years, real loan journeys collect rework loops, manual workarounds, approvals by email and exception paths that have become the norm. When a bank re-platforms on the basis of the documented process, one of two things tends to happen. Either the new system drops workarounds that people depend on, and operations struggle after go-live, or it faithfully digitises inefficiencies nobody knew were there. 

Process mining addresses this before a single requirement is written. It reconstructs the real process from the event data the bank's systems already record. This article explains why business analysts should start every lending modernisation with it, how the work is done and the gaps it typically reveals. 

Every system involved in a loan application leaves a trail: the application is created, a document is uploaded, a credit check runs, an underwriter opens the case, an offer is generated, a contract is signed, the money is paid out. Each of these records has three essential pieces of information: 

A case identifier, usually the loan application number. 

An activity, such as "Income document received" or "Manual review started". 

Put those records together in time order for every application, and you have an event log. Process mining tools, from commercial platforms such as Celonis to open-source libraries such as PM4Py, read that log and reconstruct the process automatically. They show which paths applications really take, how often each path occurs, where time is spent and where cases go back and forth. 

Three uses matter most before a modernisation: 

Discovery: drawing the real process from the data, without assumptions. 

Conformance checking: comparing the real process with the documented one and listing every deviation. 

Performance analysis: measuring lead times, waiting times and rework, step by step. 

Where the data comes from in a loan journey 

A retail or SME loan journey typically crosses several systems, and the event log has to bring them together: 

The digital channel or CRM, where the application starts. 

The loan origination system, which manages the application workflow. 

The credit decisioning engine, for scoring and automated decisions. 

Document management, where payslips, statements and contracts are stored. 

The core banking system, where the loan account is opened and funds are disbursed. 

The hard part is not the tooling. It is agreeing what counts as an activity and making sure the same application can be followed across systems that use different identifiers. This is where the business analyst's work starts. 

"Map the loan process" is too broad. A good starting question is specific: why does a standard consumer loan take eight days when the target is two? or what share of applications really goes to manual underwriting? The question decides the scope: which products, which channels and which time period. Twelve months of data usually captures seasonal effects and enough volume. 

Systems record technical events, while the business thinks in activities. The BA builds a dictionary that maps one to the other, for example: status code 140 in the origination system means "Sent to underwriting", and a document upload with type PAY means "Income proof received". This dictionary is often the most valuable artefact of the exercise, because it is the first time the bank has a shared definition of its own process steps. 

The data team extracts the events, and the BA validates them. Loan data is personal data, so customer identifiers are pseudonymised before analysis, and the data protection officer is involved from the start. Process mining needs case numbers, activities and timestamps, not customer names. 

4. Validate with the people who do the work 

Before drawing conclusions, the first results are reviewed with underwriters, back-office staff and branch advisers. They explain what the data can't: why a status is set twice, why a step seems to take zero seconds, or why some cases disappear for days. This step catches data-quality problems early and builds trust in the findings. 

Only then does the analysis begin: the real process map, the deviations from the documented process and the time spent at each step. 

Every bank is different, but in loan journeys the same kinds of gaps appear again and again. 

Many more paths than anyone expected. The documented process shows one main path with a few exceptions. The event log often shows hundreds of variants. Usually a handful of variants covers most applications, and a long tail of rare paths takes a disproportionate share of effort. Knowing which is which tells the modernisation team what to design for and what to simplify. 

Manual review is the norm, not the exception. Procedures often describe manual underwriting as an exception for complex cases. The data regularly shows a much larger share of applications being reviewed by hand, often because automated rules are set conservatively or because data needed for an automated decision arrives late. 

Document loops. Customers are asked for the same document more than once: a payslip that was unreadable, a bank statement for the wrong period, a document requested by a second department that didn't see the first upload. Each loop adds days and frustrates the customer. 

Waiting time dominates. Actual work on an application often takes minutes or hours, while the application waits for days between steps: in a queue, waiting for a hand-off between teams or waiting for a customer reply. Modernisation that speeds up the work but leaves the hand-offs untouched barely changes the lead time. 

Steps that happen outside the systems. Gaps in the timeline, followed by a sudden status change, usually point to work done by email, spreadsheet or phone. These off-system steps are exactly what a new platform needs to capture, and they are invisible in workshop-based process maps. 

Steps in the wrong order. Conformance checking sometimes finds cases where a step happened before a check that should have preceded it, for example a contract generated before a final verification was recorded. Even when there is a valid explanation, such as a check done but recorded late, these cases matter for control frameworks. The EBA Guidelines on loan origination and monitoring (EBA/GL/2020/06) expect banks to have sound, documented credit-granting processes, and process mining gives evidence of how consistently those processes are followed. 

How the findings shape the modernisation 

Process mining doesn't replace requirements work; it gives it a factual starting point. For each significant deviation, the BA leads a decision with the business owner: 

Eliminate it, because it is waste (repeated document requests, unnecessary hand-offs). 

Automate it, because it is valuable but manual (common manual reviews that a well-designed rule could handle). 

Formalise it, because it is a legitimate exception the new platform must support explicitly, instead of leaving it to email. 

The analysis also produces two things a modernisation programme usually lacks. 

A measured baseline. Lead time, waiting time, share of manual reviews, rework rate and first-time-right rate, all measured before the change. After go-live, the same measurements show whether the new platform delivered what the business case promised. 

A realistic migration picture. The real variants include applications that are in flight on the day of migration. Knowing which paths they can be in, and how many there typically are, makes the cut-over plan much more reliable. 

Process mining is powerful, but it only sees what systems record. Work done entirely outside the systems leaves no trace beyond a gap. Batch jobs can give many events the same timestamp, and statuses set retrospectively can make the process look different from how it ran. That is why the validation step with the people who do the work is not optional, and why process mining works best alongside interviews and observation, not instead of them. 

It is also an analysis of the past. It shows how the process runs today, not how it should run tomorrow. The design of the future process remains a business decision, now made with facts on the table. 

Modernising a loan journey is expensive, and the cost of building the wrong process is paid for years. Mapping the real process from event data before re-platforming takes weeks, not months, and it replaces assumptions with evidence: how many paths really exist, where time really goes and which workarounds the business can't do without. For a business analyst, it is the most reliable way to make sure the new platform is designed for the bank as it actually works, and for the bank it wants to become. 

Process Mining Before Modernisation  

Why BAs should map the real process from event data before any re-platforming, and the gaps this usually reveals between the documented process and the actual one.

Why BAs should use process mining on event data before loan modernisation, and the gaps it reveals between the documented and the real loan journey.

Mapping the loan journey as it really runs 

Flaky tests are tests that fail at random, without any change to the code. In a bank's delivery pipeline, they quietly do three kinds of damage: they waste engineering time on re-runs, they slow releases down, and they teach teams to ignore failing tests. That last effect is the dangerous one. When a red result usually means "just re-run it", a real defect can be re-run and dismissed in exactly the same way. 

Flaky tests rarely appear in a steering committee report, yet they decide how fast a bank can release and how far a green pipeline can be trusted as release evidence. This article explains why test-suite reliability belongs on a leadership dashboard, which numbers to track and how mature teams bring flakiness under control. 

What a flaky test is, and why it's a governance issue 

A flaky test is one that passes and fails on the same code, without any change. The cause is usually in the test or its environment, not in the product: a timing assumption, shared test data, an unstable test environment or a dependency on the current date. 

On its own, one flaky test is a nuisance. At scale, flakiness changes how an organisation behaves. Google's engineering team has published that almost 16% of their tests, roughly one in six, showed some level of flakiness, and that about 1.5% of all test runs reported a flaky result. Banking platforms, with their integrations, shared test environments and date-sensitive logic, are rarely in a better position. 

The governance problem is simple. In most banks, a passing test suite is part of the release decision: it is the evidence that a change was tested before it reached production. If the suite fails randomly, people stop treating red as a signal. Release gates are overridden "because it's probably flaky", and the test results that change management relies on lose their meaning. A control that is routinely overridden is not really a control. 

Time. Every flaky failure triggers a re-run, an investigation or both. Re-running a 40-minute pipeline twice a day across ten teams quickly adds up to weeks of engineering time per quarter, plus the CI infrastructure cost. Developers waiting for a green build switch context and lose more time again. 

Speed. Teams slow down to protect themselves. They batch changes into bigger releases because each pipeline run is unreliable, which makes each release riskier and harder to diagnose. Release windows get missed, and regulatory or customer-facing changes slip. 

Risk. This is the most serious cost. When failures are routinely dismissed, a real defect can be dismissed with them. The test did its job, but the organisation had learned not to listen. In a payment system, that is how a defect that the suite actually caught still reaches production. 

Test reliability can be measured, and a small number of metrics give leaders a clear view without going into individual tests. These are the ones we recommend reporting monthly, per product area: 

First-run pass rate on the main branch. The share of pipeline runs on unchanged, already-merged code that pass the first time. This is the single best indicator of trust. If code that already passed review fails on a re-run, the suite is the problem. 

Flake rate. The share of test failures that pass on retry with no code change. It shows how much of the "red" the team sees is noise. 

Re-run cost. CI hours and estimated engineer hours spent on re-runs and flaky-failure investigation. This translates reliability into money, which is the language budget discussions use. 

Quarantine size and age. How many tests are temporarily excluded because they are unreliable, and for how long. A quarantine that only grows is a growing gap in test coverage. 

Time to fix a flaky test. The median number of days from detection to repair. It shows whether the team treats flakiness as real work or as background noise. 

Gate overrides. How often a release went ahead with failing tests that were declared flaky. For governance, this is the number to watch most closely, because each override is a decision taken on the assumption that a failure didn't matter. 

These metrics need no special tooling. Most CI platforms already record re-runs and results, and a simple report built on that data is enough to start. 

Teams that get flakiness under control don't do it with a one-off clean-up sprint. They treat it as an ongoing process with clear rules. 

Detect automatically, and record retries honestly 

Automatic retries are useful, but only if they are visible. A test that fails and then passes on retry should be recorded as flaky, not as passed. The retry keeps the pipeline moving; the record keeps the problem visible. Teams that retry silently usually believe their suite is healthier than it is. 

When a test is confirmed as flaky, it moves to quarantine: it still runs and reports, but it no longer blocks the pipeline. The rule that makes quarantine work is that every quarantined test has a named owner and a fix-by date. Without both, quarantine becomes a quiet way of deleting tests. 

In banking systems, most flaky tests fall into a few familiar categories, and each has a lasting fix: 

Timing assumptions. Tests that wait a fixed time for an asynchronous process, such as a payment status update, fail when the environment is slower. The fix is to wait for the expected outcome, not for a number of seconds. In one of the best-known academic studies of flaky tests, asynchronous waiting was the most common root cause, behind 45% of the fixes analysed. 

Shared test data. Two tests using the same customer or account interfere with each other, especially when run in parallel. The fix is for each test to create the data it needs. 

Unstable shared environments. A test that depends on a shared integration environment, with a core banking stub or a third-party sandbox, fails whenever that environment is down. The fix is to virtualise those dependencies for most tests, keep a small set of true end-to-end tests, and use contract tests to cover the integration points in between. 

Dates and times. This one is specific to banking. Tests that pass all month and fail on the last business day, on a public holiday, after a payment cut-off time or when clocks change usually depend on the real date. The fix is a controllable clock in the test setup, so that end-of-month, cut-off and holiday cases are tested on purpose rather than by accident. 

Order dependency. Tests that only pass when run after another test. Running tests in random order in CI exposes these early. 

New tests are run several times in a row before they are merged. A test that can't pass ten times out of ten isn't ready. This simple rule stops most new flakiness at the door. 

Budget for reliability | Mature teams reserve a fixed share of capacity, often a small percentage of each sprint, for test reliability work, and they agree a threshold for action. For example, if the first-run pass rate drops below the agreed level, reliability work takes priority over new tests until it recovers. This turns reliability from goodwill into a managed commitment. 

What leaders can do | Test reliability improves fastest when leadership treats it as part of delivery risk rather than as an engineering detail. 

Four actions make the biggest difference: 

Put the numbers on the delivery dashboard, next to lead time and change failure rate. What gets reported gets managed. 

Treat gate overrides as exceptions that need a reason. Not to slow teams down, but to make each decision visible and to show the pattern over time. 

Fund reliability work explicitly. If it has to compete with features for capacity without any agreed budget, it will lose until an incident forces it. 

Ask about trust, not just coverage. Coverage shows how much is tested. First-run pass rate shows whether the results are believed. Both matter, but only the second tells you whether the release gate is really working. 

A test suite is only valuable if its results are trusted. When a team re-runs failures by reflex, the suite stops protecting releases, and the cost shows up as slower delivery, wasted engineering time and defects that were caught and still shipped. Measuring reliability, fixing flaky tests at their cause and treating overrides as governance decisions brings back the one thing a release gate needs: a red result that everyone takes seriously. 

The Hidden Cost of Flaky Tests 

Treats test-suite reliability as a delivery-risk metric that leaders can track, and explains how mature teams measure it and fix flaky tests.

Flaky tests slow releases and weaken release gates. How banks can measure test-suite reliability as a delivery-risk metric and fix flakiness at its source. 

Test-suite reliability as release governance 

The internal network has gone from a trusted zone behind a firewall to something every security review treats as hostile. A service mesh with mutual TLS is usually the first answer: every service gets a cryptographic identity, and every call between services is encrypted and authenticated. That is a real step forward. But in a regulated bank, "we have mTLS" is the start of the security discussion, not the end. This article covers three things we focus on when running Istio for banking microservices: rotating certificates without downtime, designing authorization policies that hold up in an audit, and the gaps mTLS leaves that the application still has to close. 

What mTLS in the mesh actually gives you 

In Istio, each workload runs with a sidecar proxy (or, in ambient mode, a node-level proxy) that holds a short-lived X.509 certificate. The certificate encodes a SPIFFE identity derived from the Kubernetes namespace and service account, for example: 

spiffe://cluster.local/ns/payments/sa/payment-orchestrator 

When two services talk, both proxies present certificates, verify each other and encrypt the connection. Three properties follow: 

Encryption in transit for all east-west traffic, without changes to application code. 

Workload authentication. The ledger service knows the caller is the payment orchestrator, not just "something on the network". 

A stable identity to write policy against. Authorization rules can refer to service accounts instead of IP addresses, which change all the time in Kubernetes. 

Spring Boot services keep speaking plain HTTP to their local proxy. The mesh handles TLS, so there is no keystore to manage in the application for in-mesh calls. 

Enforcing mTLS across a running platform is done in two phases. During migration, services run in PERMISSIVE mode, accepting both plain-text and mTLS traffic while sidecars are rolled out. Once every workload in scope has a proxy, a single mesh-wide policy makes mTLS mandatory: 

Before switching to STRICT, check which connections are still plain text. Istio's telemetry labels each request with its security mode, and a dashboard of non-mTLS requests per service tells you exactly who would break. Teams usually find a few batch jobs, monitoring agents or legacy integrations at this point, and it is much better to find them on a dashboard than in an incident. 

Rotation is where mesh security either runs quietly or causes outages. It happens at three levels, and each needs a different approach. 

Workload certificates: short-lived and automatic 

Istio issues workload certificates with a default lifetime of 24 hours and rotates them automatically well before they expire. The sidecar fetches new certificates over Envoy's Secret Discovery Service (SDS), so there is no pod restart and no dropped connections. 

Short lifetimes are a security feature. A stolen workload certificate is only useful for hours, and revocation lists become far less important. The operational requirement is that the issuing side is always available: if the control plane can't sign certificates for a day, workloads start failing. So we monitor certificate signing errors and the remaining validity of workload certificates, not only the root. 

To see exactly what a workload is presenting, use: 

istioctl proxy-config secret deploy/payment-orchestrator -n payments 

Intermediate CA: anchored in the bank's PKI 

Out of the box, Istio's control plane (istiod) acts as a self-signed certificate authority. That is fine for a test cluster, but not for a bank. In production, we plug the mesh into the bank's existing PKI: the bank's root CA, ideally with its keys in an HSM, signs an intermediate CA that istiod (or cert-manager with istio-csr) uses to issue workload certificates. This gives security teams what they expect: a root they control, an intermediate with a defined lifetime and a documented issuance chain. It also means intermediate rotation is a planned, routine operation rather than a surprise. 

Root CA rotation: the one that needs a runbook 

Rotating the root is the operation that causes outages when it's rushed, because every workload must trust the new root before any certificate signed by it appears. The sequence we follow: 

Distribute a trust bundle containing both the old and the new root to all workloads, and confirm every proxy has received it. 

Switch issuance to an intermediate signed by the new root. New workload certificates are now chained to the new root, and both old and new certificates are accepted because both roots are trusted. 

Wait for every workload certificate to rotate. With 24-hour certificates, this takes a day, plus a safety margin for workloads that were scaled to zero. 

Remove the old root from the trust bundle, and verify that no certificate chained to it is still in use. 

Each step is reversible until the last one, so it can be paused if anything looks wrong. For multi-cluster meshes, every cluster must complete step 1 before any cluster starts step 2. 

Not everything sits behind a sidecar. Spring Boot services often connect directly to Kafka, PostgreSQL, a mainframe gateway or an HSM using their own TLS. For these, Spring Boot's SSL bundles can reload certificates from files when they change, so a renewed certificate is picked up without a restart: 

            certificate: "file:/etc/certs/core-banking/tls.crt" 

            private-key: "file:/etc/certs/core-banking/tls.key" 

            certificate: "file:/etc/certs/core-banking/ca.crt" 

 Combined with cert-manager writing renewed certificates to a mounted secret, this covers the connections the mesh doesn't. Check that each client library you use supports reloading through SSL bundles; where it doesn't, plan a rolling restart before expiry. 

mTLS answers "who is calling?". Authorization policies answer "is this caller allowed to do this?". This is where the mesh delivers most of its security value, and where design discipline matters most. 

An AuthorizationPolicy with an empty spec in a namespace denies every request to workloads in that namespace that isn't explicitly allowed by another policy: 

 From there, every allowed call is an explicit rule. The result is a policy set that reads like a map of the system, which is exactly what an auditor or a new team member needs. 

Rules refer to service account identities and, for HTTP traffic, to methods and paths. Here the ledger service accepts postings only from the payment orchestrator, and read-only queries only from the statement generator: 

        principals: ["cluster.local/ns/payments/sa/payment-orchestrator"] 

        principals: ["cluster.local/ns/reporting/sa/statement-generator"] 

        paths: ["/api/ledger/accounts/*"] 

A few design rules keep this maintainable: 

mTLS and Service Mesh Security  

Certificate rotation without downtime, mesh-level authorization policy design, and where mTLS alone isn't sufficient for a regulated internal network.

mTLS and Istio for banking microservices: zero-downtime certificate rotation, deny-by-default authorization policies and the gaps mTLS alone doesn't close. 

For Internal Banking Microservices 

What "offline-first" means for a payment, and what it doesn't 

For a banking app, offline-first does not mean executing payments offline. The ledger, limits, fraud checks and the payment scheme all live on the server, and they always have the final say. 

The customer's intent is never lost. Once they confirm a transfer, the app keeps it safely, even if the connection drops or the app is closed. 

The intent is delivered exactly once. However many times the request is retried, the bank executes at most one transfer. 

The status shown is always honest. The app never says "sent" when it doesn't know, and never says "failed" when the money may have left. 

There is also a regulatory boundary. Under PSD2, Strong Customer Authentication ties the authentication to the specific amount and payee, and authenticated sessions have short validity limits. A transfer confirmed in a tunnel can be delivered when the train comes out. A transfer queued overnight should not be sent on an authentication that has expired; the app should ask the customer to confirm again. We design the queue for minutes of poor connectivity, not for days offline. 

Every transfer the app handles goes through a small set of states, and the UI shows each one explicitly: 

Queued: confirmed by the customer and stored on the device, waiting for a connection. 

Pending confirmation: a request was sent, but no answer came back. The outcome is unknown. 

Completed: the server confirmed the transfer was accepted. 

Rejected: the server refused it for a business reason (insufficient funds, limit exceeded, beneficiary blocked). 

Expired: it stayed queued longer than allowed and needs the customer to confirm again. 

The state that matters most is pending confirmation. Most double-payment bugs come from treating it as failed. 

The client: a persisted mutation queue with TanStack Query 

TanStack Query already has most of what an outbox needs. Mutations pause when the device is offline, can be persisted to storage, and can be resumed when the app starts again. Three pieces of setup make it work in React Native. 

First, tell TanStack Query when the device is online, using NetInfo: 

import NetInfo from '@react-native-community/netinfo'; 

import { onlineManager } from '@tanstack/react-query'; 

onlineManager.setEventListener(setOnline => 

  NetInfo.addEventListener(state => setOnline(!!state.isConnected)), 

 Second, register the transfer mutation by key, not inline in a component. Functions can't be serialised to storage, so a mutation restored after an app restart needs a default mutationFn to resume with: 

queryClient.setMutationDefaults(['transfer'], { 

  mutationFn: (transfer: QueuedTransfer) => api.submitTransfer(transfer), 

  retry: (failureCount, error) => isTransient(error) && failureCount < 5, 

  retryDelay: attempt => Math.min(1000 * 2 ** attempt, 30_000) + Math.random() * 500, 

Third, persist paused mutations to encrypted storage and resume them on start-up: 

const persister = createSyncStoragePersister({ 

  storage: encryptedOutboxStorage, // an encrypted MMKV instance exposing getItem / setItem / removeItem 

      persistOptions={{ persister, maxAge: QUEUE_MAX_AGE_MS }} 

      onSuccess={() => queryClient.resumePausedMutations()} 

The component that confirms the transfer is then deliberately simple: 

const submitTransfer = useMutation<TransferResult, ApiError, QueuedTransfer>({ 

function onConfirm(draft: TransferDraft) { 

    idempotencyKey: uuidv4(),     // generated once, at confirmation 

The most important line is the one that generates the key. It happens once, when the customer confirms, and the key travels with the queued transfer from then on. It is persisted before the first request is sent, so every retry (after a timeout, after a restart, after a day in a tunnel) carries the same key. 

Idempotency keys: the rules that make them work 

An idempotency key is a unique identifier the client attaches to a request, so the server can recognise a repeat and return the original result instead of executing again. Simple as the idea is, a few rules decide whether it actually protects customers: 

One key per customer intent, not per request. Generating a new key on each retry turns every retry into a new payment. 

Generate it on the device, before the first send. If the server generated it, a lost response would also lose the key. 

Send it in a header. We use Idempotency-Key, the name used by the IETF HTTP API working group's draft and by most payment APIs. 

Bind it to the request content. If the same key arrives with a different amount or IBAN, that is a client bug, and the server must reject it rather than return the earlier result. 

Scope it to the customer. Keys are unique per customer, not globally, so one customer's key can never return another customer's response. 

Keep it at least as long as the client might retry. The server's retention period must be longer than the client's maximum queue age.

The server: an idempotent transfer endpoint in Spring Boot 

On the server, idempotency only works if it is enforced by the database rather than by checks in application code. Two concurrent retries checking "does this key exist?" at the same moment will both get "no". We store keys in a table with a unique constraint on (customer_id, idempotency_key), along with a hash of the request, the processing status and the stored response. The endpoint wraps the transfer logic: 

public ResponseEntity<TransferResponse> submit( 

        @RequestHeader("Idempotency-Key") UUID key, 

        @AuthenticationPrincipal Jwt jwt, 

        @Valid @RequestBody TransferRequest request) { 

    return idempotency.execute(jwt.getSubject(), key, request, 

        () -> transferService.submit(jwt.getSubject(), request)); 

 public ResponseEntity<TransferResponse> execute(String customerId, UUID key, 

        TransferRequest request, Supplier<TransferResponse> action) { 

    String requestHash = hasher.hash(request); 

        records.insertInProgress(customerId, key, requestHash); // unique constraint 

        IdempotencyRecord existing = records.find(customerId, key); 

        if (!existing.requestHash().equals(requestHash)) { 

            return ResponseEntity.unprocessableEntity().build();          // same key, different payment 

Offline-first payments in React Native 

How to design mobile payment flows that still work on a weak connection without ever sending a transfer twice.

Design offline-first payments in React Native: persisted transfer queues, idempotency keys, safe retries and conflict handling so no transfer runs twice. 

Queued transfers, idempotency keys and resolving conflicts 

I build Angular frontends for banks, and a growing share of that work is for groups that run several brands or countries on one platform: a retail brand and a digital-only brand, or the same internet banking portal in three markets with different products and regulators. In almost every one of these programmes, someone proposes micro-frontends with webpack Module Federation. Sometimes that's exactly the right call. Sometimes it adds a distributed system where a well-structured monorepo would have been simpler. This article covers how we tell the two apart, and what it takes to run Module Federation well when it is the right answer. 

What Module Federation actually gives you 

Module Federation lets one Angular application, the shell (or host), load code from other separately built and deployed applications, the remotes, at runtime. For a banking portal, the shell usually owns login, navigation, layout and session handling, while remotes own business domains: payments, cards, loans, savings and onboarding. 

The defining property is independent deployment. The payments team can release a new transfer flow on Tuesday without rebuilding or redeploying the cards module, and the Romanian loans module can ship on its own schedule while the shell stays unchanged. Everything else in this article follows from that property: the benefits, the costs and the ownership questions. If your organisation doesn't need independent deployment, most of Module Federation's complexity buys you nothing. 

In multi-brand and multi-country banking, we've found Module Federation is worth its cost when several of these conditions are true at the same time: 

Different release cadences that can't be aligned. A country team must ship a regulatory change on a fixed local deadline, while the group release train runs monthly. Without independent deployment, one country's deadline holds up, or gets held up by, everyone else. 

Multiple teams or vendors working in parallel. When four or five teams, sometimes from different companies, contribute to one portal, clear runtime boundaries reduce merge conflicts, coordination meetings and accidental coupling. 

Country- or brand-specific products. A mortgage module that exists only in one market, or a youth account that exists only in one brand, can be a remote loaded only where it's needed. 

A long-lived platform with a large surface. Portals with dozens of journeys and a lifetime measured in years benefit from being able to rewrite or replace one domain without touching the rest. 

On the other side, these are the situations where we usually recommend against it: 

Micro-frontends for Multi-brand Banking Portals 

The trade-offs for banks running several brands or countries on one platform: shared design systems, version drift and who owns which part.

When Angular Module Federation pays off for multi-brand banking portals: runtime manifests, shared design systems, version drift and team ownership.

All News

Categories

All News

Categories

Do you want to read more?

Subscribe now for our bimonthly newsletter!