Fintech companies do not set out to build unmaintainable systems. They set out to solve a specific payment, lending, or compliance problem — usually fast, usually with a small team. The architecture that works at seed stage is typically the one that ships fastest, which is rarely the one that scales cleanly to Series B volumes, enterprise clients, and regulatory certification.
By the time modernization becomes unavoidable, the system is usually processing significant transaction volume on a codebase that was never designed for it. The team that built it may be gone. Tests are sparse. The rationale behind architectural decisions exists in Slack threads. And the business cannot stop during a rewrite.
This is not an unusual situation. It is the standard situation.
Why Most Fintech Migrations Are Announced and Never Finished
The failure mode is consistent: a modernization project is scoped, resourced, and begun. Six months in, the team discovers that the legacy system has undocumented dependencies they did not account for. The migration scope expands. A compliance requirement surfaces that was not in the original design. The original timeline doubles. By month twelve, the business has a partially migrated system, two codebases to maintain, and a team that is demoralized by the gap between what was promised and what shipped.
The numbers bear this out. Eighty percent of core banking replacements fail or are abandoned — only 20% of institutions that attempt a full core replacement actually complete it. As of 2025, 43% of financial institutions still run core systems built more than 20 years ago, and legacy maintenance consumes up to 40% of IT budgets. The hidden cost compounds further: one documented mid-sized European bank estimated €2M per year in core system costs; a full audit revealed the true figure was €6.8M once compliance overhead, engineering productivity drag, and innovation opportunity cost were included.
The failures are not primarily technical. They are scoping failures: the team did not understand enough about the system they were replacing, or the migration approach assumed conditions — stable scope, clean cutover window, predictable compliance requirements — that do not exist in production financial systems.
The Big-Bang Rewrite Is Almost Always the Wrong Approach
The appeal of a greenfield rewrite is obvious: start clean, make the right decisions from the start, avoid carrying forward the mistakes of the previous system. In practice, big-bang rewrites in payments and financial infrastructure almost never ship cleanly.
The reasons:
You cannot stop processing transactions. Payment systems operate continuously. Any architecture that requires a cutover window — where live traffic moves from one system to another in a single event — is a plan for a production incident. The old system knows things the new system does not yet know, and the cutover reveals them in production.
The old system’s behaviour becomes the specification. When you are replacing a payment reconciliation system, every edge case in the legacy codebase that was handling a real transaction scenario has to be understood and replicated or explicitly decided against. You cannot do that without spending significant time in the code you are trying to escape.
Regulatory and compliance state does not transfer automatically. PCI-DSS certification, SOC 2 reports, and regulatory approvals apply to specific systems. A rewritten system is a new system, and compliance has to be established from scratch on the new architecture.
The patterns that work are incremental: migrate one component at a time, with the old and new systems running in parallel, verifying parity at each step.
The Strangler Fig Pattern: Why It Works for Financial Systems
The strangler fig pattern — named for a species of vine that slowly envelops and replaces a host tree — is the most reliable approach to legacy payment system migration. The principle: build the new system incrementally alongside the old one, routing a progressively larger share of traffic through the new components until the old system has been entirely replaced and can be decommissioned.
For fintech, this typically means:
Extracting the payment authorization service first. Authorization is usually the most latency-sensitive component and the most self-contained. It has clear inputs and outputs, defined success criteria (authorization approved/declined), and well-understood compliance requirements. It is a good starting point because failure is immediately measurable.
Event sourcing the payment ledger. The payment ledger — the authoritative record of what money moved where — is the core of any payments system. Building it on event sourcing (an append-only log of immutable events) rather than mutable state records solves several problems simultaneously: it provides a complete audit trail for regulators, enables point-in-time replay for reconciliation, and separates the current-state view (the balance) from the history (the transactions) in a way that makes both more reliable.
Separating services by compliance scope. PCI-DSS divides systems into cardholder data environment (CDE) scope and out-of-scope components. Building the new system with explicit service boundaries around the CDE — rather than having cardholder data flow through every component as it typically does in a monolith — makes PCI-DSS Level 1 certification significantly more achievable and reduces the total cost of the annual assessment.
Reconciliation: The Hidden Engineering Problem
Manual reconciliation is one of the most common signs that a fintech system was built for speed rather than scale. A nightly batch process that reconstructs what happened during the day from database records is fine when transaction volumes are low. It becomes unsustainable when the business is processing millions of transactions, and it becomes a compliance liability when regulators ask for real-time visibility into financial position.
The root cause of manual reconciliation in legacy fintech systems is almost always the same: the system was built around mutable state. When a transaction occurs, a database record is updated. The history of what the record looked like before the update may or may not have been preserved. Reconstructing the sequence of events that led to the current state requires either a complete audit log (which many legacy systems do not have) or a manual process.
Event-driven architecture solves this by design. Every state change is represented as an event that is appended to an immutable log. The current state is derived from the history of events, not stored separately. Reconciliation is the log, not a separate process that reconstructs the log from a mutable database.
Compliance Architecture Has to Come First
The most expensive mistake in fintech modernization is treating compliance as a post-build audit. PCI-DSS Level 1, DORA, and ISO 20022 compliance requirements have architectural implications that cannot be retrofitted economically onto a system that was not designed for them.
The specific implications depend on the regulatory context, but the pattern is consistent:
- PCI-DSS requires cardholder data to be isolated in a defined perimeter, encrypted at rest and in transit, with dedicated key management and full access logging. This shapes which services can touch payment credentials and which cannot — which in turn shapes the service boundary design of the whole system.
- DORA (the EU Digital Operational Resilience Act, effective January 2025) requires financial institutions and their ICT suppliers to demonstrate operational resilience, including documented incident response, data replication, and recovery time objectives. Systems without proper observability and failover architecture cannot satisfy DORA requirements without significant architectural changes.
- ISO 20022 is gradually replacing legacy payment messaging formats (SWIFT MT, ACH) across global payment rails. Systems that have not been designed to handle the richer data structures in ISO 20022 messages face a migration problem that compounds — the downstream systems that consume payment data were designed around the old schemas.
The economics are clear: compliance requirements discovered mid-build typically increase project cost by 40–60% and delay delivery by 3–6 months. The same requirements identified in the scoping phase add maybe 20% to the initial estimate and are built correctly the first time.
Real-Time Risk Scoring: The Latency Constraint Nobody Plans For
Fraud detection and risk scoring in payments require a decision to be made in milliseconds. A rule-based fraud engine making a decision in 50ms is acceptable. A machine learning model making a decision in 500ms is not — not when the authorization response to the merchant is waiting for the model output.
This constraint is often discovered late in modernization projects. The ML model performs well in offline evaluation. It performs well in load testing with single requests. It fails when deployed into the payment authorization path, where it is called on every transaction and the P95 latency of the full authorization flow is now above what the acquiring bank’s SLA allows.
The architectural response to this constraint is not to make the model faster (though that helps). It is to isolate the latency-sensitive path from the model scoring path:
- Pre-computed risk scores for known entities (existing cardholders, established merchants) are cached and served from Redis, not computed on every transaction.
- Asynchronous scoring runs in parallel with the authorization decision, updating risk profiles and triggering reviews without blocking the transaction.
- Hard rules first: simple, computationally cheap rules that reject clearly fraudulent transactions without model inference are evaluated first. The ML model is called only when the rule layer is inconclusive.
This pattern separates the real-time authorization path from the analytical path, allows each to be scaled and optimized independently, and produces better outcomes on both dimensions.
How we approach this at Insoftex
Payments and financial platform modernization is the work we see most consistently result in scope expansion, timeline slippage, and budget overruns at other firms — and the work where we have developed the most specific opinions about what to do differently.
The most important rule we apply: we do not begin architecture work on a migration until we have spent time in the legacy codebase. Not reading documentation about the system — reading the system. The undocumented edge cases and implicit dependencies that will determine whether the migration is deliverable are in the code, not the specs. The two weeks spent understanding the existing system before writing a line of the new one typically prevents four to six weeks of rework later.
On compliance: we scope PCI-DSS, DORA, and ISO 20022 requirements before the first architecture diagram is drawn. The compliance environment shapes the service boundary design. In our payments platform engagement — migrating a PHP monolith handling €40M in annual payment volume to an event-driven microservices architecture — PCI-DSS Level 1 certification was a hard requirement on a fixed timeline. Building the CDE scope into the initial service design meant the certification process was straightforward; the compliance team was auditing a system designed for their audit rather than a system retrofitted to pass one.
We use event sourcing for payment ledgers on every engagement. The audit trail is a requirement in every regulated payments context we encounter. Event sourcing makes it an architectural output rather than an operational afterthought. The reconciliation automation that typically follows — eliminating hours of daily manual work — is a direct consequence of having the full event history as a first-class artifact.
Working on a fintech platform migration? Our fintech engineering team has shipped payment platform modernizations and compliance-critical rebuilds. See our Build & Modernize service for how we structure complex migrations, or start with a Product Pilot to validate the migration path first.