Fixing a system error after release costs four to five times more than fixing the same error during design, according to a commonly cited estimate from IBM’s Systems Sciences Institute. Left later still, in the maintenance phase, the multiplier is often quoted as climbing past 100x.
That curve does not bend the other way for compliance. In a regulated industry, it gets worse.
We call this the Retrofit Tax. Every fintech team that selects a development partner on speed alone eventually pays it. Most don’t know the bill is coming until it arrives.
The call we keep getting
A fintech CTO reached out to us earlier this year. Six months prior, their team had evaluated two development partners. One proposed twelve weeks. The other proposed eighteen.
They went with twelve.
By the time they called us, the platform was live. Transaction volumes were growing. The engineering team was proud of the build.
The problem surfaced during a pre-audit review. The audit trail their logging architecture was supposed to generate had never run consistently in production. A quarter’s worth of transaction records were incomplete. Their SOC 2 review was eight weeks out.
The partner had shipped on time.
That was the Retrofit Tax, arriving on schedule.
Why is the tax so much higher than teams expect
The mechanism is structural, not incidental. Modern Treasury’s compliance team frames it plainly: rebuilding a payment stack to retrofit compliance is a multi-quarter engineering project, and it almost always happens under an imposed deadline, not a chosen one. Nobody schedules a retrofit. A retrofit gets scheduled for you by an auditor or a regulator.
The cost compounds because compliance debt behaves differently from ordinary technical debt. Ordinary technical debt slows your own team down. Compliance debt has consequences that extend to your bank sponsors, your payment partners, and your customers’ data. You are not the only party that inherits the bill.
Industry surveys put the exposure in concrete terms: well over half of fintechs have paid at least $250,000 in compliance fines in a single year, and roughly a third have paid over $500,000. Most of that traces back to KYC, AML, and data-handling gaps that were architectural in origin, not bugs introduced by a rushed sprint. Structural gaps get built in from the start because compliance was never part of the specification.
Even the fintechs trying hardest are not immune. Many teams already doing more than the regulatory minimum still get caught out. The gap is not effort. It is architecture.
The thing nobody prices in at the RFP stage
When a fintech team selects a development partner, the evaluation almost always comes down to three variables: cost, timeline, and portfolio.
Compliance architecture is assessed through a checklist. Does the vendor know PCI DSS? Have they shipped PSD2-compliant systems? Do they have SOC 2 experience?
Those are necessary questions. They are not sufficient.
The question that matters is structural: does this partner build compliance in from the specification layer, or do they treat it as a review gate after the code is already in staging?
The difference is invisible in a sales conversation. It becomes visible the day the Retrofit Tax comes due.
Deloitte’s research on fintech risk practices names this distinction clearly. The most mature fintech organizations treat compliance not as a checkpoint at the end of the product lifecycle, but as something woven through ideation, build, and go-to-market from the start. Adyen is the benchmark case in that research: no product is scoped without compliance input, and engineering and compliance teams move together continuously, not just at milestones.
That model requires a development partner who has built that workflow into their own delivery practice. Not their pitch deck. Their practice.
What the right partnership model actually looks like
We have worked with two categories of development partners in fintech engagements.
The first delivers a build. They scope it, ship it, hand it over. Fast, clean, done. The relationship ends at launch, and the Retrofit Tax, if it comes, is somebody else’s problem to solve.
The second embeds. They carry institutional knowledge about why architectural decisions were made. They know what the compliance baseline was on day one, and can tell you whether the system still meets it on day one hundred and eighty.
Futurice’s long-running engagement with Moneycorp is one of the clearest publicly documented examples of this distinction. Rather than operating as a siloed outsourced vendor, Futurice embedded directly into Moneycorp’s teams over multiple years. The value was not delivery speed. It was continuity of context, the kind that determines whether you can defend your system in front of an examiner.
The fastest partner and the right partner are not always the same firm.
The questions that actually filter for the Retrofit Tax
We no longer evaluate development partners on timelines alone. These are the questions we ask instead:
- What does their incident response track record look like across past fintech engagements? Not whether they have a process. What actually happened in production, and how long did it take to resolve?
- How do they handle environment parity between development, staging, and production? Compliance testing results are meaningless if production behaves differently from staging.
- Have they sustained partnerships across multiple product cycles with the same client, or do their case studies all end at launch?
That last question is the most revealing. A partner confident in the durability of what they build will have clients who come back.
The reframe
The fintech teams building for the next decade are not the ones who shipped the fastest MVP last year.
They are the ones who never paid the Retrofit Tax, because their development partner priced compliance in from the first sprint instead of the first audit.
Development partnerships should be evaluated on that horizon.
The right question is not “who gets us to market fastest?” It is “who builds the kind of system we will still trust when the stakes are highest?”
Speed matters. In a regulated environment, speed without reliability is just financing for a tax you haven’t been billed for yet.
If your team is evaluating a fintech development partner, or reassessing how your current partnership is structured, NeoBank Labs builds compliance-ready payment infrastructure and digital banking platforms in the US, EU, and Australian markets, with compliance architecture priced into the build from day one, not billed later as a retrofit.
Take a look at how these engagements play out in practice in our case studies, or get in touch to talk through your architecture.
This is part of an ongoing series on production AI and compliance architecture in fintech.
