The RegTech Stack Every Digital Bank and Neobank Needs in 2026

The compliance gap no amount of cloud-native architecture closes on its own

A high-street bank with 20 years of operating history has a financial crime team that may run to 400 people, a transaction monitoring platform that cost eight figures to implement, and compliance infrastructure embedded so deeply into the organisation that it has its own politics, its own budget cycle, and its own career track. A neobank launching in 2026 has a cloud-native core, 12 engineers, a full banking licence or e-money institution authorisation, and a regulatory obligation that is, in almost every material respect, identical.

The FCA does not grade on a curve for headcount. Nor does the ECB, nor the Central Bank of Ireland, nor BaFin. Whether you have 40,000 customers or four million, the obligation to conduct adequate KYC, KYB, and AML screening, file suspicious activity reports within required timeframes, and maintain an auditable record of your financial crime controls is the same. The only viable way to meet that standard without 400 people is SaaS-native RegTech — purpose-built software that automates what incumbents built in-house over decades.

The problem is that the vendor landscape is genuinely fragmented, the integration work is non-trivial, and the wrong choices compound. A transaction monitoring tool that generates 95% false positives is technically compliant and operationally ruinous. An orchestration layer that becomes load-bearing for your entire compliance workflow is extraordinarily difficult to replace once it is embedded. This guide maps the full stack, layer by layer, and identifies what actually matters when choosing between vendors.

Layer 1: Identity verification and onboarding

The first compliance layer is also the most customer-visible. Every person who opens an account must be verified against a minimum standard — document verification, biometric liveness detection, and screening against sanctions lists and politically exposed person (PEP) databases. Get this wrong and you have onboarded someone you should not have. Make it slow or friction-heavy and you lose them to a competitor whose conversion funnel is tighter.

The core technology components are: optical character recognition plus forgery detection for document verification (checking whether the document is genuine, not just whether the data is readable); biometric liveness detection (confirming the person presenting the document is physically present and not a photo or video); and database screening against consolidated sanctions lists and adverse media sources. These three components can be bought as a single integrated product or assembled from separate vendors — a choice with meaningful integration implications.

The market leaders in the UK and EU context are relatively well-established. Onfido built its reputation on document verification accuracy and expanded its liveness product significantly before its acquisition by Entrust in 2024; the integration remains Onfido-branded and continues to be the default choice for many UK digital banks. Sumsub has taken share in markets where geographic coverage matters — if your customer base spans emerging markets, Sumsub's document library tends to be deeper. Jumio is the established enterprise player on both sides of the Atlantic, often the choice where an existing US banking partner relationship is in play. Veriff, out of Estonia, has invested heavily in fraud resistance at the liveness layer and is worth evaluating if deep-fake attack vectors are a particular concern for your customer profile.

What to weight in your evaluation: document coverage by geography (ask for specific coverage data for your target markets, not headline numbers); liveness detection accuracy against injection attacks, not just passive attacks; API latency under load (a KYC flow that adds 45 seconds to onboarding materially affects conversion rates); and critically, whether the vendor includes sanctions and PEP screening as part of the product or whether that is a separate integration. Some neobanks discover mid-implementation that their identity vendor only handles the document and biometric layer, and screening requires a separate contract with a data provider.

Layer 2: Transaction monitoring

Rules-based alert engines remain the industry baseline because regulators understand them, auditors can examine them, and they produce a documented decision trail. The problem is well-documented: a standard rules engine configured at default thresholds generates alert volumes that most compliance teams cannot process — industry false positive rates are widely cited in the range of 90–98% — though the figure varies considerably by institution, product type, and monitoring configuration — meaning that for many firms, the great majority of flagged transactions are noise rather than genuine suspicious activity. This is the primary source of compliance team burnout, and it is a compliance risk in itself: teams drowning in false positives are slower to act on the real ones.

ML-augmented monitoring is the direction of travel, but it has a significant practical constraint at launch: the models need training data, which means transaction volume, which a new neobank does not have. The practical approach is to launch with a configurable rules engine — NICE Actimize, Fiserv Financial Crime Risk Management, or Temenos Financial Crime Mitigation are the established platforms — and introduce ML-based alerting as volume grows and you have genuine behavioural data to train against. Purpose-built ML vendors can be overlaid as a second layer rather than a wholesale replacement. ThetaRay uses graph-based analysis particularly suited to cross-border payment corridors where rules struggle with complex network relationships. Featurespace uses adaptive behavioural analytics that updates individual customer baselines in near-real-time, which is powerful for detecting account takeover and mule activity that rules miss. The approach fits the wider RegTech stack; it is not a neobank-specific pattern.

The KPIs that actually matter: false positive rate (set a target and monitor it monthly — a rate above 95% is a configuration problem, not a volume problem); detection rate against known typologies from your annual financial crime risk assessment; and alert-to-SAR conversion rate, which is the most direct measure of whether your monitoring is calibrated to actual risk. A very low SAR rate in a growing neobank is a governance concern, not a success metric. When examining AI fraud detection capabilities, the quality of the feature engineering matters as much as the underlying model architecture — understand both before committing to a vendor's ML layer.

Layer 3: Sanctions screening

Sanctions screening is conceptually adjacent to KYC but operationally distinct, and conflating the two is a common mistake. Identity verification at onboarding screens a customer once, at the point of account opening. Sanctions screening must be continuous: sanctions designations are added and removed without notice by OFAC, the UK Office of Financial Sanctions Implementation, the EU, and the UN — and those changes create an obligation to screen existing customers and, critically, to screen every payment instruction against the current list before execution.

The distinction matters enormously from a liability perspective. A missed sanctions hit on a payment instruction is not a compliance process failure in the way that a missed KYC step might be characterised. Under the UK asset-freezing framework, processing a payment to a designated person can constitute a criminal offence. Under US Treasury authorities, the penalties are civil but can be existential for a small institution — the OFAC enforcement record includes settlements well above £1m for sanctions screening failures at financial institutions of comparable size to many neobanks. This is an area where underinvestment is not a cost decision; it is a risk decision with specific legal consequences.

The primary data providers are well-known: Refinitiv World-Check (now operating under the LSEG brand following the Thomson Reuters data-and-analytics divestment), Dow Jones Risk and Compliance, and ComplyAdvantage, which has built a real-time data processing pipeline that updates its consolidated list faster than some of the legacy providers. Most neobanks screen at both onboarding and at each payment instruction, using either their orchestration layer or their core banking platform's payments API to trigger the screen before settlement. The integration point with the payments flow — specifically ensuring that a screening hit creates a genuine payment hold, not just an alert — is where implementations sometimes fall short.

Layer 4: Regulatory reporting

This is the least visible compliance layer and, for many neobanks at scale, the one most likely to be held together with spreadsheets when it should not be. In the UK, FCA-authorised firms submit regulatory returns through RegData (the successor to Gabriel) on a quarterly and annual cycle — the specific returns depend on the licence type and business model. EU-regulated entities report to their national competent authority under EBA implementing technical standards, which vary somewhat by member state but follow a common template.

From January 2025, DORA adds operational resilience reporting obligations for firms in scope — including major incident reporting timelines and the requirement to maintain a register of ICT third-party dependencies. For many neobanks, DORA is the first time their regulatory reporting programme has had to interface with their engineering and vendor management functions in a structured way, and the integration complexity is not trivial.

Dedicated regulatory reporting platforms — AxiomSL (now Adenza, acquired by Nasdaq), BearingPoint Abacus, and Droit for derivatives and structured products — provide pre-built regulatory templates, automated data validation, and audit trails that satisfy the requirement for demonstrable governance around the submission process. The case for adopting one of these platforms is straightforward: spreadsheet-based regulatory reporting is a manual process that scales poorly, creates version control risk, and is difficult to evidence as adequately controlled in a regulatory examination. The case against is cost — these platforms are not cheap at launch volumes. The middle path many neobanks take is to build a structured data pipeline from the core banking platform into a reporting template early, even if the final submission process involves some manual assembly, so that the data is clean and the transition to a dedicated platform is mechanical rather than requiring data archaeology.

Layer 5: The orchestration layer

Modern neobanks do not wire identity verification, transaction monitoring, sanctions screening, and case management together with custom integration code. Or rather, the ones that try discover quickly that maintaining bespoke integrations between five different vendor APIs is a substantial engineering overhead with no business value attached to it. The orchestration layer — a compliance middleware platform — accepts data from multiple verification vendors, applies a configurable decisioning engine, routes alerts to a case management workflow, and maintains the audit trail across the entire compliance lifecycle.

The three platforms that dominate this space in the digital banking context are Alloy, Unit21, and Sardine. Alloy is the most established in the US digital banking market and has expanded its presence in the UK; its decisioning engine is particularly strong for onboarding workflows. Unit21 has built its reputation on transaction monitoring and case management, with a no-code rule-builder that allows compliance analysts to configure and tune rules without engineering support. Sardine has a fraud and compliance combined offering that is worth evaluating if fraud prevention and AML monitoring are currently handled by separate systems with limited data sharing between them.

The orchestration layer selection deserves more time and diligence than any other decision in the stack, for a simple reason: it is the hardest to replace. Identity verification vendors can be swapped with a manageable integration project. The orchestration platform, once embedded in your onboarding, monitoring, case management, and reporting workflows, becomes load-bearing infrastructure. Migration timelines are typically measured in quarters, not weeks, and require parallel-running the old and new systems through at least one regulatory examination cycle. The vendor relationship you enter here is a multi-year commitment.

Build versus buy: the honest answer

Almost always buy. The firms that built proprietary compliance stacks — Tier 1 banks, primarily — did so before the SaaS market for this infrastructure existed, in an era when the alternative to building was not buying because there was nothing to buy. They now operate 20-year-old systems that are deeply embedded in their operational workflows, impossible to retire cleanly, and staffed by specialists whose institutional knowledge is the only thing holding the configuration together. This is not a model to emulate; it is a cautionary tale.

KYC infrastructure is not a competitive differentiator. No neobank has ever won a customer because its sanctions screening system was more sophisticated than a competitor's. What wins customers is the account opening experience, the card product, the FX rates, the customer service responsiveness — none of which is meaningfully affected by whether you built or bought the compliance layer underneath. The compliance layer is a cost of operating in the market, and the question is simply how to meet that cost efficiently and without unacceptable operational risk.

A neobank building bespoke transaction monitoring in 2026 is solving a problem that 15 vendors have already solved, with the added risk of building it wrong and discovering the gap during a regulatory examination rather than a vendor RFP. The genuinely hard work in compliance is not the technology; it is the governance, the calibration, the analyst capacity, and the programme ownership. A bought stack frees the team to focus on the hard work. A built stack means the team is focused on the software instead.

What examiners actually look for

The FCA has issued a series of Dear CEO letters to digital banks and payment firms over the past three years, most recently focusing on financial crime controls. The pattern in those letters is instructive: the concern is rarely that tools are absent. It is that tools are present but inadequately maintained. The specific failure modes the FCA and its international peers return to repeatedly are worth internalising before a regulatory examination rather than during one.

Configuration is the first. Rules and thresholds calibrated to default settings from the vendor's implementation guide are not calibrated to your actual customer risk profile. A student-account neobank and a business-banking neobank have different risk profiles even if they use the same monitoring platform — the rules need to reflect that, and they need to be documented as a deliberate configuration decision, not inherited defaults.

Tuning cadence is the second. When did you last review your alert thresholds? If the answer is "at implementation," that is a gap. Transaction monitoring rules require periodic review against the actual alert output — if your false positive rate is rising, that is a signal that customer behaviour has drifted from the baseline the rules were calibrated against. The review cadence should be documented, the review outcomes should be recorded, and the decisions to change or retain thresholds should be signed off at an appropriate governance level.

Analyst capacity is the third. How many cases does each analyst process per day? What is your SLA for SAR filing from the point of alert generation? These metrics speak to whether your compliance programme is adequately resourced or whether it is technically compliant on paper but operationally backlogged in practice. A backlogged SAR queue is a compliance failure regardless of how sophisticated the upstream monitoring is.

Programme ownership is the fourth. Who owns the financial crime compliance programme at board level? Is that person appropriately qualified, genuinely empowered, and actively engaged with programme outputs — or is the MLRO role a title on an org chart with limited practical authority? Regulators assess governance, not just tooling. A well-governed programme with a moderately capable stack will consistently outperform a sophisticated technical stack with weak governance in examination outcomes.

Sources and methodology: This article draws on FCA Dear CEO letters on financial crime controls (2022–2024); EBA guidelines on internal governance; publicly available vendor documentation for named RegTech providers; and the FCA's Financial Crime Guide. No proprietary benchmark data is cited. Vendor capabilities described reflect publicly available product information.