Your Payments Diligence Missed the Real Risk

Introduction

The diligence report came back clean.

That sentence is among the most expensive in private equity. I have seen it precede eight-figure write-downs, fund timelines that slipped eighteen months, and value creation plans that required complete reconfiguration before the first post-close board meeting. In every case, the technology section of the report said the system was solid. The stack was reviewed. The CTO was interviewed. The analysts confirmed the engine was running.

What they did not confirm was whether the engine could run under the conditions the value creation plan required.

I have spent my career operating inside payments companies as Chief Product Officer at Interac, in product roles at Klarna and Nexi/Nets, and now advising firms on payments product and technology strategy. I have worked with operating partners who are among the most sophisticated technology investors in Europe and North America. And I am of the belief that even the best-resourced diligence processes are structurally unable to catch the three patterns that most reliably predict post-close technical debt in payments acquisitions.

These are not obscure edge cases. They appear in mature payments companies more often than they should and in my experience, they appear together. The diligence reports that miss them are not the work of incompetent analysts. They are the output of a process designed to answer questions the analysts know how to ask, rather than the questions a domain operator would ask first.

This paper identifies the three patterns and explains what to do about them. I am not arguing that your current diligence process is worthless it handles market, financial, and competitive risk competently. I am arguing that for payments acquisitions specifically, it is necessary but not sufficient. The missing layer is payments domain expertise applied at the product and technology level.

Market context (H1 2025): Payments represented approximately 40% of fintech M&A deal volume in the first half of 2025, generating $37.6B in exit value across 180 transactions the highest level on record. Private equity accounted for approximately 30% of that volume, with an estimated $940B in active dry powder targeting technology investments globally.

The question is whether you add that layer before you close or after.

---

Section 1: The Diligence Gap: What Your Report Actually Tells You

A standard commercial diligence engagement on a payments target will typically produce a report that covers market sizing, competitive positioning, customer and revenue analysis, and a technology assessment. Firms such as BearingPoint (which has conducted over 1,500 technology due diligences), Crosslake (focused exclusively on technology diligence for PE), Code & Co (375+ deals), and Bain (1,000+ engagements) bring genuine rigour to the technology assessment component. Code quality, architecture patterns, security posture, scalability review, team structure, and infrastructure maturity are assessed against industry benchmarks.

The technology report will tell you whether the codebase is clean or messy, whether the infrastructure is cloud-native or legacy, whether the team is well-structured or thin, and whether the system can be expected to operate at current scale. This is valuable. It is also insufficient.

What the technology report will not tell you is whether the system can operate under the conditions your value creation plan requires. This is a different question, and it requires a different kind of expertise to answer.

Here is the question I always ask first, before I look at any technology review: can someone simply explain how this product works, who the customers are on both sides of the transaction, and how the payment flows function?

I call these the baseline truths. If the answer involves complexity, hedging, or the phrase "it depends on how you define customer," the diligence has not established the foundation on which every other assessment depends. Market sizing built on a customer definition that conflates newsletter subscribers with paying users is not market sizing it is a number waiting to be corrected post-close. I have seen this exact pattern materialize and kill a deal. I will return to it.

The gap between what a generalist technology analyst can evaluate and what a domain operator sees is not a gap of intelligence or effort. It is a gap of reference class. A generalist analyst assessing a SaaS platform and a payments system uses the same framework because, from the outside, both look like software businesses. From the inside, they are completely different risk profiles.

---

Section 2: Why Payments Targets Are Different

A SaaS company with technical debt can, in most cases, iterate continuously. Engineers ship improvements, retire legacy components over time, and manage the debt as a background obligation. Users experience some performance degradation and occasional instability, but the business continues to operate and generate revenue while the debt is addressed.

A payments company with equivalent technical debt faces a categorically different consequence set. Technical debt in a payments system risks settlement failures, regulatory breaches, scheme non-compliance, and fraud exposure each with direct financial penalties attached. Payment schemes Visa, Mastercard, SWIFT, domestic real-time payment rails mandate compliance standards and levy fines for non-compliance. Regulated settlement windows are not negotiable by the engineering team. FX exposure in a multi-currency payments system does not compress to zero while you rebuild the relevant module.

The regulatory and operational environment of payments creates a constraint on how quickly technical debt can be addressed that has no equivalent in general technology companies. This is why the 18–24 month figure I use for technical debt remediation timelines in payments targets is not an exaggeration it is a conservative estimate based on my own observations across multiple acquisitions. A well-resourced team with a clear remediation plan, operating in a compliant payments environment, will take 18 months to materially reduce the technical debt that diligence missed. A team without a plan, or with the wrong plan, will take longer and spend more.

There is a second distinction that matters for diligence purposes: the regulatory visibility of a payments system creates a paper trail that a domain operator can read. Settlement reports, scheme compliance filings, incident logs, and regulatory correspondence tell a story about how the system actually performs under production conditions. This is not a story that appears in a standard technology assessment. It requires someone who knows what they are looking at.

I am not arguing that generalist technology diligence providers should be replaced. I am arguing that for payments targets, they need to be supplemented by someone who can read that paper trail and translate it into investment risk.

---

Section 3: Three Patterns That Predict Post-Close Technical Debt

In my experience working inside and alongside payments companies across Europe and North America, three patterns appear consistently in targets where post-close technical debt materially delayed value realization. Each pattern is invisible to generalist analysis. Each is immediately recognizable to a domain operator. And each has a diagnostic question that surfaces it before you close.

These patterns do not appear in every payments acquisition. But when they appear, they are reliably expensive and they appear together more often than deal teams expect.

Pattern 1: Knowledge Concentration Risk

The diligence team reviews the technology documentation. The documentation is sparse. The analysts note it as a finding "documentation could be improved" and move on. The CTO interview goes well; the individual is clearly capable and articulate about the system. The team passes the diligence.

What the generalist analyst sees: a working system with a capable leader and some documentation debt. Manageable.

What a domain operator sees: a system whose continued operation and future development depends almost entirely on the memory of two or three individuals. If those individuals leave which they commonly do following a payments acquisition, particularly when the acquisition price creates a financial exit for the founding team nobody understands how the system works at the level required to change it.

This is the difference between a product organization and a maintenance organization. A product organization is building the future of the product. A maintenance organization is working full time to keep the existing system operational. The diligence report cannot reliably distinguish between them because both look functional on the day of assessment.

I have seen this pattern materialize in a specific way that I return to often when briefing operating partners. An investment firm closed on a payments target whose core transaction processing system had been built five years earlier as an MVP a proof of concept designed to validate the market hypothesis, not to serve as the permanent backbone of a scaled business. The MVP had worked well enough that the company never rebuilt it. By the time of the acquisition, the system was approaching end of life, and the team members who had built it and understood its full architecture had mostly moved on. The rebuild cost and timeline were not in the investment thesis. They were not in the value creation plan. The diligence report did not surface them because the analysts did not know to ask whether the system they were reviewing was the system built to prove the concept or the system built to scale. In this case, the architecture still had no API versioning on core transaction endpoints, and settlement logic remained concentrated in legacy stored procedures that predated the current service layer.

The diagnostic question: Can someone who joined the company in the last twelve months explain, end to end, how a transaction enters the system, clears, settles, and is reported without consulting anyone who was part of the founding team? If the answer is no, the knowledge is concentrated. The risk is real.

Pattern 2: Open-Source Licensing Exposure

The analyst reviews the technology stack. Open-source components are present throughout Redis for caching, Elasticsearch for logging and search, Terraform for infrastructure provisioning. The analyst notes this as a strength: modern tooling, low licensing costs, active communities, no vendor lock-in.

What the generalist analyst sees: a well-selected, cost-efficient technology stack.

What a domain operator sees: three specific tools whose license terms have all changed within the last four years, each in ways that created significant commercial exposure for companies relying on them.

In January 2021, Elastic changed the license for Elasticsearch and Kibana from Apache 2.0 a permissive open-source license to the Server Side Public License and Elastic License 2.0. The practical effect for companies offering managed Elasticsearch services was significant enough that Amazon Web Services forked the project entirely, creating OpenSearch as a BSD-licensed alternative. In September 2024, Elastic returned Elasticsearch and Kibana to OSI-approved open-source status by adding AGPLv3 as a license option. The AGPL carries its own commercial implications for acquirers: any modifications to AGPL-licensed software must be released under AGPL, which affects proprietary value claims. The risk has changed character since 2021, not disappeared.

In August 2023, HashiCorp changed the license for Terraform, Vault, Consul, and its other core tools from the Mozilla Public License 2.0 a weak copyleft license with broad commercial permissibility to the Business Source License 1.1. The BSL prohibits using the software to build competing services without a commercial agreement. The response from the developer community was significant enough that the Linux Foundation created OpenTofu, a fork of Terraform under the original MPL 2.0, which has since attracted substantial enterprise adoption.

In March 2024, Redis changed from the BSD 3-Clause license to a dual-license model: the Redis Source Available License v2 and the Server Side Public License v1. Cloud providers offering hosted Redis at scale responded by adopting Valkey forked from the pre-license-change codebase under BSD license with Linux Foundation backing. In May 2025, Redis added AGPLv3 as a third license option in Redis 8.0, a partial return toward OSI-approved open source. The fork ecosystem persists and has significant enterprise adoption. As with Elastic, the current Redis AGPL option carries copyleft obligations that affect proprietary value claims. The pattern of change is itself the risk worth managing: license terms for commercially important open-source components are not permanent, and the pace of change is accelerating.

I am not citing these examples to argue against open source. These are mature, well-supported tools, and their communities have responded to each license change with credible alternatives. My argument is different: for a PE-backed acquirer who has paid a multiple on proprietary value creation, the open-source licensing profile of the target is an IP and competitive exposure that requires active management not a line item in the technology section that reads "modern stack, low licensing costs."

The asymmetry matters. For a startup racing to market, copyleft obligations and community momentum are genuine speed advantages. For an acquirer who has purchased the right to exploit the technology commercially, these same characteristics become liabilities if the license terms change or if the company's use case falls outside the newly permitted range.

There is a positive case worth noting from the other direction. A German paytech company I encountered during a diligence review had built exceptionally robust developer documentation and cultivated an active open-source community around its core product. The original diligence evaluated this as a neutral characteristic neither a risk nor a material value driver. In reality, the developer ecosystem functioned as an extension of the engineering team, accelerating the pace of shipping improvements and dramatically reducing the cost of onboarding new capabilities. The acquisition was priced without this factor. The acquirer discovered it post-close. Open-source community health can be a significant asset or a significant liability, and generalist diligence consistently fails to evaluate it in either direction.

The diagnostic question: For each open-source component critical to the core transaction path, what is the current license, has it changed in the last three years, and what would migration to a compatible alternative cost in engineering time and elapsed calendar?

Pattern 3: Infrastructure Platform Dependency

The analyst reviews the infrastructure. The system runs on hardware or a cloud environment approaching end of life. The company has a cloud migration on the roadmap. The analyst notes it as a planned initiative and moves on.

What the generalist analyst sees: a known migration project, accounted for in the roadmap.

What a domain operator sees: no credible migration plan. An assumption that lift-and-shift will work. And a fundamental misunderstanding of what lift-and-shift means for a payments system.

Lifting a payments system from on-premises infrastructure or a legacy cloud environment to a hyperscaler AWS, Azure, GCP without re-architecting it is not a cloud migration. It is a translation of on-premises architecture into cloud infrastructure. The company pays cloud pricing for on-premises performance. The capabilities of the cloud platform auto-scaling, managed services, serverless compute, distributed caching are not utilized because the system was not designed for them. The latency profile of the new environment may differ from the legacy environment in ways that affect transaction processing times, settlement windows, and scheme compliance thresholds.

This pattern is compounded by the regulatory environment of payments specifically. Moving a payment system to a new infrastructure platform requires regulatory notification in most jurisdictions and scheme compliance re-certification in many. These requirements add time and cost that were not included in the migration estimate because the estimate was produced by an engineering team, not a team with payments regulatory experience.

My estimate, based on multiple payments infrastructure migrations I have observed or led, is that a payments system migrating from on-premises to cloud infrastructure requires 18 months of elapsed time for a competent team with a credible plan. Teams without a credible plan, or teams operating under the constraint that the existing system must remain continuously operational through the migration window, take longer. The value creation plan that assumed "cloud migration completed in Year 1" is now 18 months behind before the operators have shipped a single product improvement on the new platform.

The diagnostic question: What is the lifecycle stage of every infrastructure platform the core payment path depends on? For any platform approaching retirement, does a migration plan exist that specifies the target architecture, the migration approach beyond lift-and-shift, the regulatory notification and re-certification requirements, the scheme compliance obligations through the migration window, the engineering resource required, and the elapsed timeline by milestone? If no such plan exists, that cost and timeline belong in the investment thesis.

---

Section 4: The Compound Cost Why 18–24 Months Is Not an Exaggeration

Each of the three patterns creates independent delays and unbudgeted costs. Pattern 1 knowledge concentration means the team cannot move the product forward at the pace the value creation plan assumed. Pattern 2 open-source licensing exposure means engineering resource is diverted to IP assessment, license triage, and potential migration work that was not in the plan. Pattern 3 infrastructure platform dependency means the cloud migration line in Year 1 is not a completed initiative but a multi-year project with regulatory, scheme compliance, and engineering dimensions that were never scoped.

When two of these patterns appear together which in my experience is common in mature payments targets the cumulative impact exceeds the sum of the parts. A team with concentrated knowledge, responding to a license change that requires migrating a critical component, while planning a cloud migration with inadequate documentation of the current state that team is not executing the value creation plan. That team is in crisis management, and will remain there until the backlog of unaddressed infrastructure and knowledge debt is resolved.

Per McKinsey's July 2020 survey of 50 CIOs at financial-services and technology companies with revenues above $1B, published in "Tech debt: Reclaiming tech equity," the average technology organization directs 10–20% of the budget intended for new capabilities toward servicing technical debt instead. In payments companies where the technical debt has regulatory and scheme compliance dimensions, I am of the belief that this figure understates the impact for the targets where all three patterns are present.

The 18–24 month figure is my personal estimate, derived from observing multiple payments acquisitions where two or more of these patterns appeared together. I have not found an independent study that validates this specific timeline for the payments context the figure comes from my own observations across these engagements, anchored to the 18-month infrastructure migration estimate I describe in Pattern 3 and compounded by the sequential nature of the remediation work across all three patterns. What I have found is corroboration that the underlying dynamic is both real and common. BearingPoint's published analysis of their 1,500+ deal dataset found that 85% of businesses experienced medium-to-severe technology remediation requirements within 90 days of close, and that more than half had significant unbudgeted IT funding requirements that materially changed deal models. The pattern diligence clears the deal, post-close remediation costs consume the return is not unique to payments. My contention is that payments is where it most predictably and most expensively appears, because the regulatory and scheme compliance environment removes the ability to defer the remediation indefinitely.

The 18–24 month figure translates directly to fund timeline impact. A PE acquisition with a five-year hold period and a value creation plan that assumed material product improvement beginning in Year 1 is now executing that plan on a Year 2 or Year 3 start. The payback period extends. Follow-on capital requirements increase. Exit multiple compresses. None of this appears in the diligence report because the diligence report confirmed the engine was running, not whether it could run under the conditions the plan required.

---

Section 5: What to Demand From Your Next Payments Diligence

I am not recommending that you change your existing diligence providers. BearingPoint, Crosslake, Code & Co, and Bain are competent firms that cover what they are built to cover. The argument of this paper is that for payments targets, they need a complementary layer payments domain expertise applied at the product and technology level. The same three patterns and diagnostics apply to corporate and strategic acquirers as well; the integration economics differ, but the execution drag is similar when these risks are missed. Here is what that layer should deliver.

Checkpoint 1: Base Case Documentation

Before any technology assessment proceeds, an independent party with payments domain expertise should be able to answer, from the target company's documentation and without the assistance of the founding team: how does this product work, who are the customers on both sides of the transaction, and how do the payment flows function?

If this cannot be answered clearly from documentation alone, flag it as a red finding not a documentation improvement opportunity. The inability to document baseline truths is direct evidence of knowledge concentration risk. It is also frequently a signal that the customer metrics the deal was priced on have not been defined with precision.

The customer definition pattern warrants a specific note. A payments company that counts newsletter subscribers and paying transaction users in the same customer figure is presenting a larger addressable base than the product currently serves. A domain operator's first response to any presented customer metric is: show me how this number is constructed. If the construction is opaque or requires multiple layers of explanation, that is the finding not the number itself.

Checkpoint 2: Software Community and Licensing Health

The technology assessment should include a systematic mapping of open-source dependencies with three specific questions for each critical component: What is the current license? Have the terms changed in the last three years, and if so, what was the commercial impact on companies in equivalent use cases? What would migration to a compatible alternative cost in engineering time and elapsed calendar?

This is not a speculative exercise. Redis, Elastic, and HashiCorp have all changed license terms in the last four years, and each has demonstrated that the direction of change is not one-way Redis and Elastic have both since moved toward OSI-approved licenses while retaining AGPL copyleft obligations that carry their own commercial implications. There is no basis to assume this is the last cycle of change. A payments target whose core infrastructure depends on components that have already changed license terms once should have that risk treated as a scheduled event in the value creation plan, not an unknown tail risk.

The same assessment should evaluate community health as a potential value driver. The undervalued German paytech acquisition I described represents a real and quantifiable asset that a generalist process will miss. The right question is not "does the target use open source?" It is: is the target a contributor to the community or only a consumer? Is the community growing or declining? Are there commercial competitors who have already begun migrating to alternatives?

Checkpoint 3: System Lifecycle Stage

Every system in the core payment path transaction processing, settlement, reconciliation, scheme connectivity should be assessed for its lifecycle stage: early and still proving itself, mature and stable at scale, or approaching end of life with a migration required.

For any system assessed as approaching end of life, the domain assessment should require a credible migration plan as a condition of the technology sign-off. A credible migration plan specifies: target architecture, migration approach beyond lift-and-shift, regulatory notification and re-certification requirements, scheme compliance obligations through the migration window, engineering resource required, elapsed timeline by milestone, and commercial cost. If no credible plan exists, that cost and timeline belong in the investment thesis.

---

Conclusion: The Real Risk Is What You Did Not Ask

The most expensive diligence failures I have observed in payments acquisitions were not the result of incompetent analysts or dishonest sellers. They were the result of a diligence process that confirmed what it was designed to confirm the system is working, the market is real, the financials are defensible without asking whether the system could deliver the future the investment thesis required.

The three patterns I have described knowledge concentration risk, open-source licensing exposure, and infrastructure platform dependency are not detectable from a standard technology assessment because they require payments-specific reference points to recognize. A generalist analyst reviewing a payments target assesses code quality, architecture patterns, and security posture against industry benchmarks. They do not ask whether the MVP architecture from five years ago has survived as the production backbone of a scaled business. They do not map open-source license terms against the company's commercial use case and the recent history of the open-source license market. They do not evaluate a cloud migration roadmap against the regulatory re-certification requirements that govern payments infrastructure migration in the jurisdictions where the company operates.

These are domain-specific questions. They require domain-specific expertise to ask and to answer. The cost of that expertise a focused product and technology assessment by someone who has operated inside payments companies at the level where these questions live is a rounding error relative to 18–24 months of delayed value realization. A focused domain-specific assessment of this kind can typically be scoped for €30,000–€80,000 for a four-to-six-week engagement. For a representative €150M payments acquisition with a value creation plan that assumes €15M in product-led revenue growth beginning in Year 1, an 18-month delay in that growth program defers more than €22M in revenue at plan. At a 10x exit multiple, that is over €220M in deferred exit value. My estimate of the assessment cost range is illustrative and will depend on scope and target complexity; the specific revenue figures in your value creation plan are yours to supply. The order of magnitude of the comparison does not change materially regardless of the inputs.

I have been deliberate in this paper about what it is not. It is not a critique of any specific diligence firm. It is not a comprehensive due diligence methodology. It is a transfer of pattern recognition from someone who has seen these failures happen to the people with the authority and the access to prevent them.

The question to ask before your next payments acquisition is not "did the technology diligence come back clean?" It is: do I know, from someone who has operated inside payments companies, whether the product and technology can actually deliver the value creation plan?

If you cannot answer yes to that question, you have not finished your diligence.

---

Ted Bowman is the Founder of Outside Context, an advisory firm specializing in payment scheme strategy, cross-border payments economics, and fintech growth. He has previously served as Chief Product Officer at Interac and in product and strategy roles at Klarna, Nexi/Nets and other fintechs.