The RegTech Stack Every Digital Bank and Neobank Needs in 2026

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

An established bank may have a large financial-crime function and compliance infrastructure embedded over decades. A new neobank is likely to have a smaller team and a cloud-native core, but authorisation does not come with a small-firm exemption from managing financial-crime risk. The detailed obligations still depend on licence type, activities, customers and jurisdictions.

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 market is fragmented, the integration work is non-trivial, and the wrong choices compound. Poorly calibrated monitoring can generate more alerts than a team can investigate effectively. An orchestration layer that becomes load-bearing for the compliance workflow can be difficult to replace once embedded. This guide maps the stack layer by layer and identifies what matters when comparing vendors.

Layer 1: Identity verification and onboarding

The first compliance layer is also the most customer-visible. A firm must apply the identity, due-diligence and screening measures required for its product and risk assessment. Document verification and biometric liveness are common components of remote onboarding, but they are not a universal statutory minimum for every person or channel. FATF's digital identity guidance^[1] instead focuses on whether a digital identity system is sufficiently reliable and independent for the circumstances. Weak checks create financial-crime exposure; needless friction can damage completion rates.

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.

Identity vendors differ in document coverage, liveness methods, screening integrations, deployment model and support for a firm's target jurisdictions. Public marketing materials can describe those capabilities, but they do not establish that one provider is the default choice, has deeper coverage or is superior for a particular risk. A buyer should request current coverage by target document and country, independently test liveness and injection-attack controls, confirm screening and case-management integrations, and assess data handling, service levels, audit evidence and exit options.

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 common because their logic can be documented and reviewed. Their weakness is not a universal false-positive percentage: alert quality varies materially by institution, product, risk appetite, rule design and tuning. Poorly calibrated rules can create unmanageable queues and distract analysts from higher-risk cases. Buyers should therefore require evidence from a representative data set and should not rely on vendor or industry-wide headline rates.

ML-augmented monitoring can be considered alongside configurable rules, but the appropriate approach depends on data, typologies, explainability, validation and analyst operating model. New firms may have limited internal behavioural history, while established firms still need evidence that any model improves a defined control outcome. Buyers should test scenarios on representative data, document model and rule governance, and confirm how alerts, investigations and human decisions are recorded. Purpose-built analytics can complement rather than automatically replace an existing monitoring system.

Useful management information includes alert volumes, ageing and backlogs; disposition quality; repeat alerts; rule performance against known typologies; and the relationship between alerts, investigations and SAR decisions. None has a universal good threshold, and a low or high SAR conversion rate is not meaningful without context. When examining AI fraud detection capabilities, teams should understand the features, validation, explainability, change control and human review around the model rather than buying on a headline accuracy figure.

Layer 3: Sanctions screening

Sanctions screening is conceptually adjacent to KYC but operationally distinct. A one-time onboarding check is not enough for a changing sanctions regime. Firms need controls appropriate to their exposure so that new and amended designations are reflected in customer and transaction screening. In the UK, the authoritative starting point is the UK Sanctions List^[2]; firms operating in other jurisdictions must identify the lists and legal regimes applicable to them.

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 is where implementations sometimes fall short, specifically in ensuring that a screening hit creates a genuine payment hold rather than just an alert.

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, including AxiomSL (now Adenza, acquired by Nasdaq), Regnology (formerly BearingPoint's Abacus suite, spun out to Nordic Capital in 2020 and rebranded in 2021), 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.

Examples of orchestration and case-management vendors include Alloy, Unit21 and Sardine. Their product scopes overlap but are not identical, and capabilities change frequently. A buyer should test the required workflows, integrations, audit trail, access controls, model or rules governance, data residency and exit arrangements against its own requirements rather than infer suitability from market positioning.

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

Build-versus-buy is a capability, cost and control decision. A purchased product can reduce implementation work, but does not remove responsibility for configuration, data quality, governance and ongoing validation. An internal build can be justified where a firm has a specific product, geography or risk requirement that available products do not meet, but it creates a continuing specialist maintenance and assurance obligation.

Compliance infrastructure is primarily a control function, but its design can affect onboarding, customer support, operational cost and the evidence available to a regulator. The decision should weigh customer experience alongside regulatory obligations, resilience, implementation effort, total cost, data portability and the firm's ability to operate the control effectively.

Transaction monitoring is not solved merely by selecting a product. Governance, calibration, analyst capacity, data quality and programme ownership remain material whether components are bought or built. A procurement or build decision should include documented requirements, testing, control evidence, implementation ownership, data export and an orderly exit plan.

What examiners actually look for

FCA publications repeatedly show that owning compliance tools is not the same as operating effective controls. Its 2025 customer-due-diligence review^[3], for example, identifies weaknesses in business-wide risk assessments, customer risk assessments, due diligence, enhanced due diligence, ongoing monitoring, policies and governance. Those are useful tests for a technology programme because software must serve a documented control objective.

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 simply 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.

Methodology: CloudFintech grouped controls by the decision evidence a regulated firm needs to retain, rather than by vendor marketing category. The map is a procurement framework, not a minimum legal stack.

Primary sources: FATF Recommendations; FCA Financial Crime Guide; Regulation (EU) 2022/2554 (DORA)

Download underlying dataset