Engineering due diligence in a FinTech acquisition moves faster than most acquirers expect and surfaces more risk than they prepare for. A standard technology due diligence checklist covers codebase quality, architecture scalability, and security posture. FinTech acquisitions require all of that plus a category of risk that general tech diligence does not cover: compliance controls embedded in application code, regulatory licenses tied to specific technical implementations, and payments infrastructure dependencies that do not transfer cleanly to a new owner.
The CTO running this diligence (whether as the acquirer evaluating a target or the target preparing for scrutiny) needs a framework built for the FinTech context. This checklist covers the six engineering dimensions that determine deal risk in FinTech M&A.
What Makes FinTech Engineering Due Diligence Different
Generic tech diligence frameworks consistently underestimate three categories of risk specific to FinTech:
Regulatory controls embedded in software. AML transaction monitoring, KYC verification, sanctions screening, and fraud detection rules are not separate compliance systems in most FinTech companies. They are logic embedded in the application layer. Assessing compliance posture requires reading the code, not just the policy documents. A system that passes an audit because exceptions were manually approved, but whose automated controls are inadequate, is a liability that transfers with the acquisition.
License dependencies on technical implementations. Many FinTech regulatory licenses (e-money licenses, payment institution authorizations) are tied to specific operational and technical conditions. A change in technology infrastructure (migrating cloud providers, decommissioning a legacy system, or changing data residency) can trigger a license review. This creates post-acquisition integration constraints that standard tech diligence will not surface.
Core banking and payments integration debt. FinTech companies in banking or payments often carry deep integrations with legacy core banking systems, card networks, or payment schemes. These integrations are expensive to maintain, difficult to re-engineer, and create hard dependencies that constrain architectural decisions for years after close. The true cost of preserving or untangling this infrastructure needs to be assessed before signing, not discovered during integration.
The CTO's Engineering Due Diligence Checklist
1. Codebase and Architecture Health
Architecture documentation. Is there current documentation of the system architecture? Undocumented systems are harder to integrate and more expensive to maintain post-close.
Service boundary clarity. Are services or modules well-bounded, or is the codebase a monolith with unclear responsibilities? Monolithic architectures are not inherently disqualifying, but they affect integration complexity and scaling cost.
Technology currency. What proportion of the stack uses end-of-life frameworks, languages, or dependencies? Technology currency affects both security exposure and post-acquisition hiring.
Build and deployment reproducibility. Can you reproduce the build from source? Deployments that rely on undocumented manual steps or environment-specific state introduce continuity risk the acquirer inherits.
Test coverage. What is the automated test coverage across business-critical paths? Coverage below 40% on payment flows or compliance logic should be treated as a quantifiable risk, not a backlog item to fix post-close.
Code quality metrics. Code complexity scores, duplication rates, and static analysis results from tools like SonarQube or Codacy translate architectural risk into developer-day estimates: the language deal teams understand.
2. Delivery Performance
Delivery metrics provide an objective, data-grounded view of engineering team maturity that is harder to stage than curated presentations. The four DORA metrics (deployment frequency, lead time for changes, change failure rate, and mean time to recover) give a system-level view of how the team actually operates. Teams in the Elite or High performer bands present lower integration risk and lower post-close operational risk than teams in the Low band regardless of what their documentation says.
Deployment frequency. How often does the team deploy to production? Infrequent deployments indicate higher release risk and slower post-acquisition velocity.
Lead time for changes. How long does code take from commit to production? Long lead times signal bottlenecks in review, testing, or deployment that will affect the acquirer's post-close roadmap delivery.
Change failure rate. What percentage of deployments cause an incident or require a hotfix? A rate above 15% indicates systematic quality gaps. Above 30%, the team cannot safely ship to production at pace.
Mean time to recover. When incidents occur, how quickly is service restored? Poor MTTR indicates observability and incident response immaturity, which carries direct risk in a regulated environment. For how to interpret these benchmarks in a FinTech context, see the DORA metrics for FinTech guide.
3. Compliance and Regulatory Controls
This section is FinTech-specific and consistently under-assessed in standard technology due diligence.
AML and KYC implementation. Is transaction monitoring logic automated or manual? What are the thresholds and rules? When were they last reviewed against current regulatory guidance? Manual AML processes that work within current transaction volumes often fail at scale, and that failure becomes the acquirer's problem.
Sanctions screening. Is there real-time sanctions screening against current OFAC and HM Treasury lists? What is the false positive rate and what does the manual review process look like? Gaps here carry direct regulatory liability.
PCI-DSS posture. If the company handles card data, what is the current PCI-DSS compliance level? Is there a current Report on Compliance (RoC) or Self-Assessment Questionnaire (SAQ)? Who is the qualified security assessor?
SOC 2 status. Is there a current SOC 2 Type 2 report? What was the observation period, and were any exceptions noted? Exceptions in a Type 2 report indicate controls that passed design review but failed in sustained operation.
Data residency. Where is customer financial data stored and processed? Are there regulatory requirements under GDPR, the EU DORA banking regulation, or local financial services rules that constrain post-acquisition architecture decisions? For targets with AI-powered decisioning systems (credit scoring, fraud detection), review their compliance posture against the EU AI Act and DORA governance requirements.
Incident and breach history. Were there any regulatory reportable incidents in the past 24 months? How were they handled and what was the regulatory response? Open remediation commitments made to a regulator transfer with the acquisition.
4. Security Posture
Penetration testing. When was the last independent penetration test and by whom? What findings were reported and which remain open? Open critical findings older than 90 days indicate a non-functional remediation program.
Vulnerability management. Is there an automated scanning program across code, dependencies, and infrastructure? What is the mean time to remediate critical CVEs? In regulated FinTech, unpatched critical vulnerabilities older than 90 days represent a direct compliance risk under frameworks like NIS2 and the EU DORA banking regulation.
Access control. Is access to production systems controlled through a well-documented PAM solution or access control system? Is there a current access review history? Production access without access review history is a SOC 2 and ISO 27001 finding waiting to be discovered.
Secrets management. Are credentials and API keys managed through a dedicated tool (HashiCorp Vault, AWS Secrets Manager) or present in configuration files and environment variables? Hardcoded secrets in a codebase are a liability that requires immediate remediation post-close.
5. Technical Debt and Modernization Risk
Debt quantification. Has technical debt been measured? Tools like SonarQube provide technical debt estimates in developer-days, converting architectural risk into integration cost. An undisclosed backlog of 18 months' remediation work changes the cost model of an acquisition.
Legacy system dependencies. What systems does the target depend on that it does not control: third-party banking APIs, legacy core banking connections, card scheme interfaces? What are the SLAs and known failure modes? These dependencies do not disappear after close.
Planned modernization. Is there a current roadmap for addressing known technical debt? Has it been resourced? Work that is planned but not resourced is debt that transfers at face value.
Scalability constraints. Has the architecture been load tested? Where are the known capacity ceilings? FinTech companies running close to capacity limits represent operational risk that materializes under post-acquisition growth.
6. Team and Knowledge Concentration Risk
Key person risk. Is critical system knowledge concentrated in one or two engineers? The most common post-acquisition failure mode in FinTech is the departure of the engineer who owns the payments integration. Map the knowledge, not just the org chart.
Documentation quality. Is there sufficient documentation for a new team to maintain and extend the system without the original authors? In FinTech, this is a compliance question as much as an operational one.
Retention signals. What is the engineering team's tenure and retention rate over the past 12 months? Post-acquisition attrition in FinTech engineering teams is a consistent integration risk, particularly in compliance engineering and infrastructure roles.
Open headcount. Are there unfilled engineering roles, particularly in compliance engineering, platform infrastructure, or security? Unfilled roles are operational gaps that become the acquirer's hiring problem and timeline from day one.
Red Flags That Change Deal Terms
Certain findings in FinTech engineering diligence have historically changed deal structure, valuation, or the decision itself:
- No automated AML or KYC controls. Compliance logic implemented as manual processes rather than code is a systemic risk. Remediating it post-close is expensive and creates direct regulatory exposure in the interim.
- Unremediated critical CVEs older than 90 days. Indicates a non-functional vulnerability management program with direct regulatory implications under DORA banking regulation and NIS2.
- Change failure rate above 30%. At this level, the team cannot safely deploy to production at pace. Post-acquisition velocity is effectively zero until the underlying quality issues are addressed.
- Single engineer owns the payments integration. Loss of that individual post-close makes the core business unpredictable. This is not an operational inconvenience. It is deal risk.
- Open regulatory findings. Remediation commitments made to a regulator (FCA, ECB, FDIC) do not close at signing. They transfer to the acquirer as obligations with deadlines.
Using Engineering Analytics in the Diligence Process
Engineering analytics platforms give acquirers an objective view of delivery performance that is harder to misrepresent than policy documents or self-reported metrics. Connecting to the target's GitHub, Jira, and CI/CD tools produces real DORA metrics, PR cycle times, and deployment history: the actual record of how the engineering organization has operated, not a prepared presentation of it.
Scrums.com connects to 50+ engineering tools and surfaces the delivery performance metrics, code quality analytics, and team velocity data directly relevant to the diligence questions above. For the engineering team's specific responsibilities in a SOC 2 audit, see SOC 2 for Engineering Teams. For FinTech engineering leaders building or assessing a compliance-first engineering operation, see the FinTech Engineering Playbook for the full operating framework.
Frequently Asked Questions
What is engineering due diligence in M&A?
Engineering due diligence in M&A is a structured assessment of a target company's technical assets, architecture, delivery capability, security posture, and compliance controls. The goal is to quantify technical risk before close, identify liabilities that affect valuation, and surface integration considerations that affect post-acquisition timelines and costs.
What makes FinTech engineering due diligence different from standard tech DD?
FinTech engineering diligence adds three layers that standard tech diligence frameworks typically miss: compliance controls embedded in application code (AML, KYC, sanctions screening), regulatory license dependencies tied to specific technical implementations, and core banking or payments integration debt that constrains post-acquisition architecture decisions. Standard checklists assess the technology stack; FinTech diligence also assesses the regulatory risk transferred through it.
How long does technical due diligence take in a FinTech acquisition?
Most FinTech technical due diligence processes run two to four weeks, depending on the complexity of the target's architecture and regulatory footprint. Compliance controls review (AML logic, PCI-DSS evidence, SOC 2 documentation) typically adds one to two weeks beyond standard code and architecture review. Compressing the timeline without a structured checklist increases the probability of missing compliance-specific risk.
What DORA metrics benchmarks indicate low acquisition risk?
DORA Elite performer benchmarks are deployment frequency of multiple times per day, lead time for changes under one hour, change failure rate below 5%, and mean time to recover under one hour. High performer bands are acceptable for most acquisition contexts. Low performer metrics, particularly a change failure rate above 15% or MTTR above 24 hours, indicate engineering maturity concerns that affect post-acquisition delivery risk.
What are the most common engineering deal-breakers in FinTech M&A?
The most common engineering findings that change deal terms in FinTech M&A are: manual rather than automated AML/KYC controls, open regulatory remediation commitments that transfer to the acquirer, critical security vulnerabilities with no active remediation program, and knowledge concentration risk where one or two engineers own undocumented mission-critical systems. Each represents a post-close liability that either requires immediate investment or constrains integration timelines.
For hands-on support assessing or building a FinTech engineering organization, start a conversation with our team.
