Regulatory Warnings Neobank Compliance PSD2 / GDPR Art. 22 February 2026 — Regulatory Analysis

Revolut Compliance Lessons: HMRC Penalties, Bank of Lithuania Warnings, and What Neobank AI Programs Must Fix

Revolut’s compliance history is the most documented case study in what happens when a FinTech scales its technology faster than its compliance program. HMRC penalties equivalent to approximately €3.5 million for tax compliance failures, Bank of Lithuania supervisory warnings in 2022 and 2023 documenting AML program deficiencies, and a three-year UK banking licence saga that finally concluded in July 2024 — together these cases document the compliance program gaps that AI-powered neobanks systematically develop when growth velocity outpaces regulatory infrastructure. The lessons apply directly to every FinTech deploying automated customer onboarding, GDPR Article 22 automated decisions, and PSD2-regulated payment services.

Bank of Lithuania Supervisory Action: Revolut Bank UAB

Regulator: Bank of Lithuania (Lietuvos Bankas)
Actions: Supervisory warnings and required compliance remediation 2022/2023
Nature: AML/CFT program deficiencies; inadequate internal controls; compliance program gaps during rapid customer growth phase
Regulatory context: Revolut Bank UAB holds Lithuanian banking licence, making Bank of Lithuania its primary prudential supervisor
Official source: Bank of Lithuania Supervisory Notices — lb.lt

HMRC Compliance: Revolut Tax Reporting Failures

Authority: HM Revenue & Customs (UK)
Approximate penalty equivalent: ~€3.5 million in HMRC-related penalties and compliance costs
Nature: Tax reporting and compliance failures associated with rapid UK employee headcount growth and international payroll complexity
Official source: Published financial statements — Revolut Group Holdings Ltd annual reports (Companies House)

1. The Neobank Growth-Compliance Gap: Revolut as a Case Study

Revolut’s compliance history is not the story of a company that disregarded regulations. It is the story of a company whose technology and customer acquisition capabilities consistently outpaced its compliance program development — a pattern that is structurally inherent to VC-backed FinTech growth models where speed-to-market is the primary competitive metric and compliance is treated as a cost to be minimised rather than a capability to be built.

The specific regulatory challenges Revolut faced are instructive because they are not unique to Revolut. They are the predictable compliance failure modes of the neobank growth model:

AML Program Scalability

AML controls calibrated for a startup customer base fail at scale. Revolut’s Bank of Lithuania warnings identified deficiencies in AML controls that had not kept pace with customer acquisition speed. The same pattern appeared in the FCA’s Monzo investigation and Starling’s £29M fine.

Internal Controls Maturity

Neobanks typically build technology first and governance second. Internal controls that are adequate for a 500-person company become inadequate for a 5,000-person company with banking licences in multiple jurisdictions. The transition point is predictably accompanied by regulatory scrutiny.

Multi-Jurisdiction Compliance Complexity

Operating under a Lithuanian banking licence, FCA e-money authorisation, and HMRC obligations simultaneously creates compliance complexity that requires dedicated multi-jurisdiction expertise. Generic compliance frameworks applied across all jurisdictions will fail in each one.

45M+

Revolut customers globally at time of UK banking licence grant (July 2024)

Revolut became the UK’s largest FinTech by customer count before receiving its UK banking licence. Operating at this scale under e-money institution status rather than banking licence status meant customers lacked FSCS deposit protection — a regulatory gap that PRA supervision specifically addressed before the licence was granted.

2. PSD2 Compliance for AI-Powered Payment Features

The Payment Services Directive 2 (EU Directive 2015/2366, PSD2) creates specific requirements for payment service providers that are directly relevant to AI-powered payment features. For Revolut and other neobanks operating under PSD2 licences, three PSD2 provisions have particular AI compliance significance:

Strong Customer Authentication (SCA) Under PSD2 Article 97

PSD2 Article 97 requires strong customer authentication for electronic payments above defined thresholds, with specific exemptions for low-risk transactions. AI fraud scoring is used by many PSPs to apply the transaction risk analysis (TRA) exemption under RTS Article 18 — which permits SCA to be waived for low-risk transactions identified by a fraud monitoring system meeting defined performance thresholds.

The RTS performance thresholds are demanding: to use the TRA exemption for transactions above €100, a PSP must demonstrate a fraud rate below 0.01% for card transactions and 0.005% for credit transfers. These thresholds must be monitored in real time and the exemption must be suspended if fraud rates exceed them. An AI fraud scoring system used for TRA exemption decisions must therefore be validated against these precise performance benchmarks, not merely against general fraud detection accuracy metrics.

Liability Shift Under PSD2 Article 74

PSD2 Article 74 establishes that where a payment service provider fails to apply SCA, it bears the loss from any resulting fraud. For AI systems that incorrectly apply the TRA exemption — waiving SCA for transactions that turn out to be fraudulent — the liability shift provisions mean the PSP cannot claim against the consumer for the fraudulent transaction. This creates a direct financial exposure for AI TRA systems with false-negative fraud rates that exceed the RTS thresholds.

Open Banking API Requirements and AI Data Access

PSD2 requires account servicing payment service providers (ASPSPs) to provide open APIs for access by third-party providers (TPPs). For AI-powered financial management and lending FinTechs that rely on PSD2 data access for their models, the consistency and completeness of ASPSP API data directly affects model quality. Disruptions to PSD2 API access can produce the same training data degradation problem as changes to any other key data source — but the degradation may not be immediately visible in the model’s output metrics.

GDPR Article 22 is the provision most directly relevant to AI-powered financial services: it establishes that data subjects have the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects. For neobanks using AI for credit decisions, account opening, transaction limits, and product eligibility, Article 22 creates compliance obligations that many have not fully implemented.

The three legal bases under which automated decision-making is permissible under Article 22(2) are:

Necessary for a contract: Where the automated decision is necessary for entering into or performing a contract with the data subject. Credit scoring is the canonical example — but the automated decision must be genuinely necessary for the contract, not merely convenient.
Authorised by Union or Member State law: Where national legislation specifically authorises automated decisions for the relevant purpose. UK GDPR Schedule 2, paragraph 5 provides a specific basis for automated decisions by financial services firms for the purpose of assessing creditworthiness.
Based on explicit consent: Where the data subject has given explicit (not merely informed) consent. Consent must be freely given, specific, informed, and unambiguous — pre-ticked boxes or broad consent clauses do not meet this standard.

The Article 22 Compliance Gap in Neobank AI: Many neobanks have relied on the “necessary for a contract” basis for automated credit and onboarding decisions without adequately documenting why the specific automated decision (as opposed to a human decision) is necessary for the contract. Data protection authorities across the EU have indicated that “necessary” means genuinely necessary — not commercially preferred. Automated decisions that could be made by a human reviewer do not qualify as “necessary” merely because an automated system is cheaper to operate.

Where Article 22 applies, the data subject is entitled to: obtain human intervention in the decision; express their point of view; and obtain an explanation of the decision and challenge it. For neobanks, implementing these rights requires a human review escalation pathway for automated credit and onboarding decisions that is genuinely accessible to customers — not buried in a privacy policy or available only through a customer service process that never results in the automated decision being actually reviewed by a human.

// GDPR Article 22 Compliant Automated Decision Architecture
// Required safeguards for automated decisions with "legal or similar" effects

const automatedDecisionRecord = {
  decision_id: "auto_dec_7f4a2b",
  decision_type: "credit_limit_reduction",   // "legal or similar" effect
  customer_id: "cust_891234",
  timestamp: "2024-11-15T09:14:23Z",

  // Article 22(3) required safeguards
  safeguards: {
    legal_basis: "necessary_for_contract",   // Must be documented and defensible
    human_review_available: true,            // Not just stated in policy -- genuinely available
    human_review_pathway: {
      contact_method: "in-app_request",
      response_sla: "5_business_days",       // Must be defined and met
      actual_human_reviewer: true            // Actual human, not AI re-evaluation
    },
    explanation_provided: {
      factors: ["payment_history", "income_change", "utilisation_rate"],
      plain_language: true,                  // Not "model weights"
      actionable: true                       // Customer can understand how to improve outcome
    },
    right_to_object: {
      process_documented: true,
      objection_pathway: "support@example.com",
      binding_on_firm: true                  // Objection must produce genuine review
    }
  },

  // Data retention: Article 5(1)(e) storage limitation
  retention_period: "6_years_from_decision", // Financial services standard
  deletion_scheduled: "2030-11-15"
};

4. Neobank Compliance Program Requirements Under PRA/FCA Dual Regulation

When Revolut received its UK banking licence in July 2024, it moved from FCA-only supervision (as an e-money institution) to FCA/PRA dual regulation as an authorised deposit-taker. This transition represents a qualitative change in compliance obligations that neobanks seeking banking licences must anticipate:

PRA Fundamental Rules and Internal Capital Adequacy Assessment Process (ICAAP): Banking institutions must maintain capital buffers adequate for their risk profile, assessed through the ICAAP. For AI-powered neobanks, the ICAAP must include AI-specific operational risk assessment — including the financial impact of AI system failure on the bank’s capital position and the adequacy of capital held against AI operational risk.

Senior Managers Regime and Controlled Functions: Under dual regulation, neobanks must map all Senior Managers and Controlled Functions to the PRA’s regime as well as the FCA’s SM&CR. This creates specific accountability requirements for AI system oversight that must be documented in Statements of Responsibilities and Responsibilities Maps.

Operational Resilience (SS1/21 and PRA Policy Statement PS6/21): Banks must identify their Important Business Services, set impact tolerances, and demonstrate the ability to remain within those tolerances during severe but plausible operational disruptions. For AI-dependent banks, AI system failure is explicitly an operational resilience scenario that must be tested. Neobanks that have never conducted a realistic AI failure scenario test are not compliant with PRA operational resilience requirements.

5. 12-Item Neobank AI Compliance Program Checklist

Neobank AI Compliance Program Audit Checklist — PSD2, GDPR Art. 22, UK Reg

GDPR Article 22 decision inventory: Identify every automated decision your systems make that produces legal or similarly significant effects on customers. For each: document the legal basis (necessary for contract, Union/Member State law, or explicit consent); implement the required safeguards (human review pathway, explanation capability, right to object); and verify the safeguards are genuinely operational rather than merely documented.

PSD2 TRA exemption performance monitoring: If your payment systems apply the PSD2 Transaction Risk Analysis exemption from SCA, implement real-time monitoring of fraud rates against RTS performance thresholds (<0.01% for remote card transactions above €100 threshold). Document the monitoring process and the procedure for suspending the TRA exemption when thresholds are approached.

Multi-jurisdiction AML calibration: Document that AML controls are calibrated separately for each jurisdiction in which you operate. Bank of Lithuania supervisory expectations, FCA Dear CEO letter requirements, and FinCEN BSA requirements are not interchangeable. Generic AML controls applied across all jurisdictions will be inadequate in each one.

UK banking licence operational resilience: For firms holding or seeking UK banking licences, conduct and document operational resilience scenario testing specifically for AI system failure. Define impact tolerances for AI-dependent Important Business Services and verify the ability to remain within those tolerances during AI system outages.

Human review pathway operationality: Test that Article 22 human review pathways are genuinely operational — not just described in privacy documentation. Conduct test requests for human review of automated decisions and measure the time to response, the qualification of the reviewer, and whether the review produces a genuine reconsideration rather than a re-confirmation of the automated decision.

Open banking API data quality monitoring: For AI models relying on PSD2 open banking data inputs, implement monitoring of data quality and completeness from ASPSP APIs. API disruptions or data quality degradation can produce silent model performance deterioration. Document fallback procedures for model behaviour when API data is unavailable or degraded.

FSCS deposit protection communication: For firms operating under e-money licence rather than banking licence, ensure that customers are clearly informed about the absence of FSCS deposit protection and the safeguarding regime that applies instead. Automated onboarding flows that do not make this distinction clear create consumer harm and regulatory risk.

AML compliance growth projection: Conduct annual projection of AML control capacity requirements at projected customer growth rates. For neobanks targeting aggressive customer acquisition, project whether current AML controls — alert review capacity, SAR filing capability, human oversight infrastructure — are adequate at the projected scale 12 months forward. Pre-emptive capacity building is significantly cheaper than post-enforcement remediation.

Data minimisation for AI training (GDPR Art. 5): Verify that customer data used to train or fine-tune AI models is processed under an appropriate legal basis and that data minimisation principles are applied. AI models trained on all available customer data without purpose limitation assessment are likely processing personal data in violation of GDPR Article 5(1)(b) purpose limitation and Article 5(1)(c) data minimisation.

SM&CR AI accountability mapping: For FCA-regulated firms, map each AI system used in regulated activities to a named SMF holder with documented accountability for that system’s governance. Under SM&CR, diffuse accountability for AI systems — shared across engineering, product, compliance, and the technology vendor — is not accountability. One named individual must be able to attest to each system’s fitness for regulatory purpose.

Consumer Duty vulnerable customer AI protocol: For FCA-regulated neobanks, implement and test a vulnerable customer identification and routing protocol within automated systems. FCA FG21/1 guidance requires that automated processes can identify and appropriately handle customers who may be in financial difficulty or otherwise vulnerable. Test the protocol with realistic vulnerable customer scenarios to verify it produces appropriate outcomes, not merely that it exists.

Cross-border data transfer compliance: For neobanks with EU-based processing infrastructure serving UK customers (or vice versa), verify that cross-border data transfer mechanisms — Standard Contractual Clauses, adequacy decisions, Binding Corporate Rules — are current and documented. Post-Brexit UK-EU data flows are subject to the UK Adequacy Decision (which the EU issued in June 2021 but which is subject to review) — monitor for changes that would affect the legal basis for transfers.

6. How Claire Supports Neobank Compliance Program Development

Claire’s Neobank Compliance Architecture

Article 22 Automated Decision Management System

Claire maintains a complete record of every automated decision subject to GDPR Article 22, including the legal basis applied, the explanation generated, the human review pathway activated, and the outcome of any objection process. This system creates the documentary evidence of Article 22 compliance that data protection supervisory authorities (ICO, CNIL, Lithuanian State Data Protection Inspectorate) require when investigating automated decision-making practices in financial services.

PSD2 TRA Performance Dashboard

For payment service providers using the PSD2 TRA SCA exemption, Claire provides a real-time TRA performance dashboard tracking fraud rates against RTS thresholds by transaction type and value band. When fraud rates approach the exemption threshold, the dashboard generates automated alerts to designated compliance personnel. If thresholds are breached, the system automatically triggers the TRA exemption suspension protocol and generates the regulatory notification documentation required by the RTS.

Multi-Jurisdiction AML Calibration Management

Claire maintains separate AML threshold configurations and typology libraries for each jurisdiction in which a client operates. When Bank of Lithuania, FCA, or FinCEN supervisory guidance is updated, jurisdiction-specific calibration parameters are reviewed and updated accordingly. Clients receive notifications when supervisory developments in their operating jurisdictions require AML control recalibration.

Compliance Capacity Growth Modelling

Claire’s compliance capacity planning module projects AML alert volume, SAR filing requirements, and human review capacity needs at defined customer growth scenarios. For neobanks planning aggressive customer acquisition campaigns, the module identifies the compliance infrastructure investment required to maintain regulatory compliance at projected scale — before the gap becomes a supervisory problem rather than a planning question.

7. The Compliance Lesson Revolut Documents

Revolut’s compliance journey — HMRC penalties, Bank of Lithuania warnings, FCA scrutiny, and a three-year banking licence process — is not a story of regulatory failure. It is a story of regulatory remediation: a company that encountered the predictable compliance consequences of growth-at-any-cost culture and then, under sustained regulatory pressure, built the compliance infrastructure it should have built before scaling. The banking licence it received in July 2024 represents the outcome of that remediation.

Every neobank and FinTech currently in the growth phase of Revolut’s 2018-2021 trajectory faces the same compliance inflection point. The question is whether to build compliance infrastructure before regulators demand it — which is cheaper, faster, and preserves customer trust — or after, which means enforcement actions, remediation programs, and the kind of regulatory relationship that makes subsequent licence applications and product launches materially more difficult.

Building compliance infrastructure for your neobank’s growth phase? Claire works with FinTechs and neobanks to design PSD2-compliant, GDPR Article 22-compliant, and FCA/PRA-ready compliance architectures that scale with customer growth rather than breaking under it. Talk to Claire about neobank compliance.