Banking regulation was historically designed around identifiable institutions, physical branches, account-based records and relatively stable service channels. Digital finance has altered each of these assumptions. A customer may now obtain credit through a mobile application, make a payment through a technology platform, access several accounts through an application programming interface (API), or use a financial service embedded in an online marketplace. The regulated activity may be performed by a bank, a telecommunications company, a cloud provider, a fintech firm, a crypto-asset intermediary, or several of them jointly.

This transformation creates substantial benefits: lower transaction costs, wider access, faster payments, more personalized services and improved competition. It also creates regulatory risks. These include cyberattacks, operational concentration, unauthorized data use, discriminatory automated decisions, weak consumer understanding, fraud, money laundering, unstable stablecoins and unclear responsibility across complex service chains.

The central regulatory question is therefore not simply whether a technology is innovative. It is whether the activity creates risks associated with money, credit, payments, data, market integrity, financial stability or consumer protection—and which party is responsible for controlling those risks.

Regulatory approaches differ by jurisdiction. The discussion in this chapter presents widely used principles and illustrates them with major international developments. Students must always consult the law, supervisory guidance and licensing rules applicable in the relevant country. Examples include the European Union’s payment and data rules, the Digital Operational Resilience Act (DORA), the Markets in Crypto-Assets Regulation (MiCA), the EU Artificial Intelligence Act, the United Kingdom’s operational-resilience and consumer-duty approaches, United States prudential and consumer-protection rules, and international standards issued by bodies such as the Financial Stability Board (FSB), the Basel Committee, the Financial Action Task Force (FATF) and the Bank for International Settlements (BIS).

Learning objectives

1. A technology-neutral regulatory perspective

A useful starting principle is same activity, same risk, same regulatory outcome, while recognizing that proportionality may justify different requirements for small or low-risk providers. Technology-neutral regulation does not mean identical regulation for every firm. It means that a payment, deposit-like product, lending decision or investment service should not escape oversight merely because it is delivered through an app or platform.

A second principle is substance over form. A product described as a “wallet,” “token,” “credit marketplace” or “buy-now-pay-later” facility may have economic characteristics equivalent to a payment account, stored-value instrument, loan or investment product. Supervisors examine function, legal claims, custody arrangements, redemption rights and risk transfer rather than marketing language alone.

A third principle is proportionality. Controls should reflect the size, complexity, systemic importance and risk profile of the service. Proportionality is not permission to ignore fundamental safeguards. Even a small fintech normally needs controls for customer identification, complaints, cybersecurity, data protection, fraud and business continuity.

Question	Regulatory concern
What activity is performed?	Licensing and perimeter
Who bears the risk?	Prudential and contractual responsibility
Whose data is processed?	Privacy, consent and security
How is the decision made?	Conduct, fairness and model risk
What happens if the system fails?	Operational resilience and redress
Could misuse threaten the financial system?	Financial stability and systemic oversight

2. Mobile banking and digital channels

Mobile banking includes account access, payments, transfers, digital onboarding, remote deposit, personal financial management and mobile lending. The regulatory risks are not limited to the application itself. They extend to the device, operating system, telecommunications network, authentication provider, cloud environment, identity-verification supplier and payment infrastructure.

2.1 Consumer and conduct risks

Mobile interfaces can make transactions fast but difficult to understand. A customer may authorize a payment using a biometric prompt without appreciating whether it is a recurring instruction, an international transfer or an irreversible crypto-asset transaction. Important terms hidden behind hyperlinks can undermine informed consent.

Banks and fintechs should therefore use clear disclosures, accessible design, confirmation screens for high-risk transactions, transaction limits, cooling-off mechanisms where appropriate, complaint channels and effective reimbursement procedures. Regulation commonly addresses unauthorized transactions, fraud liability, safeguarding of customer funds, unfair terms and misleading advertising.

2.2 Digital identity and anti-money laundering

Remote onboarding requires reliable customer due diligence (CDD). Controls may include identity-document verification, biometric comparison, liveness detection, database checks, sanctions screening, beneficial-ownership analysis and ongoing transaction monitoring. Each control has failure modes. Facial recognition may produce different error rates across demographic groups; document systems may reject legitimate customers; automated monitoring may generate excessive false positives.

A risk-based approach is preferable to a purely mechanical one. The institution should document why a control is appropriate, test its performance, provide escalation routes and retain evidence for audit. Digital convenience cannot remove obligations under anti-money-laundering and counter-terrorist-financing frameworks.

2.3 Cybersecurity and operational resilience

Mobile banking requires secure authentication, encryption, secure software development, patch management, fraud analytics, incident response and tested recovery arrangements. Multi-factor authentication reduces some risks but does not eliminate social engineering, SIM swapping, malware, credential theft or malicious insiders.

Operational resilience differs from simple business continuity. It asks whether important business services can continue within tolerated disruption limits, even when a supporting system or provider fails. Institutions should identify critical services, map dependencies, set impact tolerances, test severe but plausible scenarios and notify regulators and customers when required.

3. Open banking and API-based finance

Open banking allows authorized third parties to access account information or initiate payments, normally with customer permission and through standardized APIs. It can promote competition and enable budgeting tools, account aggregation, comparison services and innovative payment experiences.

3.1 Consent and data governance

Consent should be specific, informed, freely given where required by law, time-limited where appropriate and capable of withdrawal. A customer should know what data will be accessed, for what purpose, by whom and for how long. Data minimization requires collecting only what is reasonably necessary.

Open banking also creates a tension between portability and confidentiality. A data recipient may infer sensitive information from transaction histories, including health, religion, political activity or financial distress. Strong access controls, purpose limitation, retention rules, encryption and third-party oversight are therefore essential.

3.2 Liability and dispute resolution

A transaction involving several institutions can produce uncertainty about who must investigate a failed or unauthorized payment. Regulatory frameworks and contracts should allocate liability clearly and ensure that the consumer is not left without a practical remedy while firms dispute responsibility. Banks should perform due diligence on third-party providers, monitor API activity and maintain the ability to suspend unsafe access.

3.3 Competition and concentration

Open banking seeks to reduce dependence on incumbent banks, but the ecosystem may become dependent on a small number of API aggregators, cloud platforms or identity providers. Competition policy and operational-resilience supervision must therefore consider both bank concentration and technology concentration.

4. Embedded finance

Embedded finance integrates a financial service into a non-financial customer journey. Examples include insurance offered during travel booking, credit offered at an online checkout, a wallet inside a social-commerce platform, or a payment account embedded in business software.

The principal regulatory difficulty is blurred responsibility. The platform often controls the interface and customer relationship, while a regulated bank supplies the balance sheet or license. Customers may not know which entity holds their funds, makes the credit decision, handles complaints or protects data.

The bank cannot normally outsource accountability merely by outsourcing performance. It must conduct due diligence, approve the service design, monitor outcomes and retain sufficient expertise to challenge the technology provider.

5. Crypto-assets and stablecoins

A crypto-asset is a digital representation of value or rights that can be transferred and stored electronically, often using distributed-ledger technology. Categories differ legally, but may include payment tokens, utility tokens, asset-referenced tokens, e-money tokens, security tokens and governance tokens. Classification determines whether securities, payments, banking, commodities, consumer or specialized crypto regulation applies.

Risks include extreme price volatility, fraud, market manipulation, cyber theft, private-key loss, conflicts of interest, inadequate custody, misleading promotion, sanctions evasion and money laundering. Decentralized technology does not necessarily mean decentralized risk. Developers, issuers, exchanges, custodians, stablecoin reserve managers and governance bodies may exercise substantial control.

5.1 Stablecoins

A stablecoin seeks to maintain a stable value relative to a reference asset, such as a fiat currency. Stability may be supported by reserves, collateral, algorithms or a combination of mechanisms. A reserve-backed model does not guarantee stability: the quality, liquidity, legal segregation and valuation of reserves are decisive.

A simplified reserve coverage ratio can be used as an internal monitoring indicator:

where RCR is the reserve coverage ratio, V_R is the current eligible reserve value in currency units, and V_C is the value of outstanding stablecoin claims in the same currency units. The ratio is meaningful only if “eligible reserves” are precisely defined, valued conservatively and available for redemption. A ratio above 1 does not by itself prove solvency, liquidity or legal enforceability.

5.2 Financial-crime controls

Crypto intermediaries generally require risk-based CDD, transaction monitoring, sanctions controls, record keeping and controls for transfers involving unhosted wallets, subject to local law. Blockchain transparency is not equivalent to customer identification. Addresses may be pseudonymous, funds may pass through mixers or bridges, and transaction histories may be difficult to interpret.

6. Central bank digital currencies

A CBDC is a digital liability of a central bank. It differs from commercial-bank money, which is a liability of a commercial bank, and from most crypto-assets, which do not represent a central-bank claim. A CBDC may be retail, for public use, or wholesale, for financial institutions and settlement activity.

Design choices include account-based versus token-like access, direct versus intermediated distribution, offline functionality, privacy architecture, holding limits, remuneration, programmability and cross-border interoperability. Each choice has regulatory consequences.

Potential benefits include resilient public payment infrastructure, faster settlement, financial inclusion and greater competition. Potential risks include privacy intrusion, cyberattack, operational failure, disintermediation of banks and rapid movement of deposits into central-bank money during stress. A holding limit may reduce disintermediation but can complicate user experience and monetary-policy design.

CBDC governance must address legal tender status, data access, identity, AML controls, operational responsibility, offline fraud, interoperability and redress. Privacy should be designed into the system rather than treated as a later technical feature.

7. Artificial intelligence in finance

Artificial intelligence in banking includes statistical machine learning, natural-language systems, computer vision, recommendation systems and generative AI. Applications include fraud detection, credit underwriting, customer support, anti-money-laundering alerts, collections, treasury forecasting, cybersecurity and regulatory reporting.

The regulatory risk depends on the use case, not merely on whether a system is called AI. A customer-facing chatbot that answers general questions creates different risks from a model that rejects mortgage applicants or determines suspicious-transaction alerts.

7.1 Model risk

Model risk is the possibility that a model produces adverse consequences because of errors in design, data, implementation, use or interpretation. A useful decomposition is:

Here, TP means true positives, FP false positives and FN false negatives. Precision answers: of cases flagged positive, how many were actually positive? Recall answers: of actual positive cases, how many were detected? The measures have no universal “best” value; the appropriate balance depends on the cost of missed fraud, customer harm, investigation capacity and legal requirements.

For credit models, institutions should also monitor calibration, stability, discriminatory impact, override rates, default performance and outcomes across relevant segments. A model can be accurate overall and still systematically disadvantage a protected group.

7.2 Algorithmic bias and fairness

Algorithmic bias may arise from historical discrimination, unrepresentative samples, proxy variables, measurement error, label bias or feedback loops. Removing a protected attribute does not guarantee fairness because variables such as postcode, occupation, language or spending patterns may act as proxies.

These criteria can conflict, particularly when groups have different base rates. Consequently, fairness requires legal interpretation, institutional values, customer-impact analysis and governance—not only optimization of a statistical metric.

7.3 Explainability and transparency

Explainability has at least three audiences. Customers need understandable reasons and information about review or appeal. Managers need enough insight to monitor limitations and make decisions. Supervisors and auditors need evidence of design, validation, controls and outcomes.

A technically complex model is not automatically unlawful, but opacity increases governance difficulty. Institutions should document intended purpose, data lineage, features, training process, performance boundaries, known limitations, version history and decision logic. Post-decision explanations should be meaningful rather than generic statements such as “the algorithm determined that you were ineligible.”

7.4 Human oversight

Human oversight is effective only when the human has competence, authority, time and access to relevant information. A nominal reviewer who merely accepts automated recommendations provides little protection. Oversight should include escalation thresholds, override procedures, independent review, monitoring for automation bias and suspension authority.

For high-impact decisions, a bank may use a “human-in-the-loop” approach, in which a person approves each decision, or a “human-on-the-loop” approach, in which a person supervises an operating system and intervenes when predefined conditions arise. The appropriate design depends on risk, volume, reversibility and legal requirements.

8. Responsible AI governance framework

Stage 1: Inventory and classify

Maintain an inventory of models and AI systems. Record owner, purpose, data, supplier, affected customers, decision significance, jurisdiction, dependencies and retirement date. Classify systems by impact and risk.

Stage 2: Define permissible purpose

State what the system may and may not do. Prohibit uses that conflict with law, customer expectations, privacy commitments or institutional risk appetite. Confirm that the use case has a lawful basis and a genuine business need.

Stage 3: Govern data

Assess accuracy, representativeness, provenance, consent or other legal basis, retention, security and sensitive attributes. Establish controls for training data, prompts, retrieval sources and generated outputs. Generative AI requires particular attention to confidential-data leakage and fabricated content.

Stage 4: Develop and validate

Use independent validation proportionate to risk. Test accuracy, robustness, fairness, explainability, cybersecurity, drift and worst-case behavior. Compare the model with simpler alternatives; complexity should produce demonstrable value.

Stage 5: Approve and deploy safely

Obtain approval from appropriate risk, compliance, legal and business authorities. Use pilot testing, staged rollout, transaction limits and fallback processes. Ensure customers are informed where automated processing materially affects them.

Stage 6: Monitor and respond

Monitor outcomes, error rates, fairness indicators, complaints, overrides, drift, incidents and supplier performance. Establish thresholds that trigger investigation, retraining, restriction or shutdown.

Stage 7: Retire and learn

Securely delete or archive data according to legal requirements, preserve records needed for audit, inform affected stakeholders where necessary and document lessons learned.

A three-lines model supports accountability: business and technology teams own day-to-day controls; risk and compliance functions challenge and oversee; internal audit independently assesses the framework. The board remains responsible for governance and risk appetite even when development is outsourced.

9. Regulation of third-party technology and cloud services

Digital finance often depends on a small set of cloud, payment, identity, cybersecurity and data-analytics providers. Outsourcing can improve capability but creates concentration, lock-in and exit risks. A bank should assess financial soundness, security architecture, subcontracting, data location, audit rights, resilience, incident notification, business continuity and termination assistance before contracting.

Contracts should not be treated as a substitute for supervision. The institution must understand the service sufficiently to monitor it and must ensure that regulators can obtain information and conduct examinations. Important services require tested exit plans, alternative providers or credible manual procedures.

10. Integrated illustrative case: a digital lending platform

Background

Northstar Bank partners with ShopLink, an online marketplace, to offer instant working-capital loans to small merchants. ShopLink supplies transaction histories and recommends loan amounts. Northstar funds the loans, owns the credit risk and uses a machine-learning model to make decisions. A cloud provider hosts the model, while an identity firm performs onboarding.

Problem

After six months, approval rates are substantially lower for merchants using a minority-language interface. Complaints increase because applicants receive only the message “application declined.” Internal audit also discovers that ShopLink has not clearly explained that marketplace data will be used for credit assessment. During a cloud outage, manual processing is unavailable.

Analysis

The arrangement involves embedded finance, outsourcing, open-data governance and automated credit decisions. Northstar remains accountable for lending conduct and model governance even though ShopLink controls the customer interface. The language disparity may indicate unrepresentative training data, translation errors, proxy discrimination or differences in data completeness. The lack of reasons weakens explainability and appeal. The outage demonstrates inadequate operational resilience.

Approach and solution

Northstar should first suspend automatic adverse decisions for the affected segment while preserving access to a fair manual review. It should conduct a data-provenance assessment, compare approval, error and default outcomes across language groups, test translated disclosures and examine whether missing data is being interpreted as negative evidence.

The bank should redesign the consent notice, identify the legal basis for using marketplace data, and explain the material factors influencing decisions. It should establish a customer appeal route and record human overrides. Independent validation should test the model on representative data and compare it with a simpler baseline.

The partnership contract should specify responsibility for disclosures, complaints, incident reporting, audit access, subcontractors and data deletion. Northstar should create a fallback process for loan applications during cloud disruption and test it periodically.

Outcome

In this illustrative resolution, the bank finds that the original training data underrepresented minority-language merchants and that a data-completeness feature acted as a proxy for language. The feature is removed, the model is retrained and approval outcomes are monitored. Customers receive clearer reasons and a review option. ShopLink corrects its consent process, and Northstar introduces a tested manual workflow.

Learning points

11. Contemporary regulatory developments and professional practice

Contemporary regulation is converging around several themes. First, regulators increasingly apply horizontal requirements to operational resilience, cybersecurity, data protection and third-party risk. Second, AI frameworks commonly use risk tiers, imposing stronger controls on high-impact applications such as credit, insurance, employment and essential services. Third, crypto-asset frameworks increasingly distinguish issuance, custody, exchange, market abuse and stablecoin activities. Fourth, supervisors expect evidence of governance rather than broad ethical statements.

A compliance professional should maintain a regulatory-perimeter map, conduct horizon scanning and translate legal requirements into controls, owners, evidence and testing schedules. Useful evidence includes model cards, data inventories, impact assessments, validation reports, incident logs, supplier reviews, customer notices, complaint analyses and board reporting.

Best practice is not to treat innovation and compliance as opposing goals. Early legal and risk involvement can prevent expensive redesign. A controlled experimentation environment, regulatory sandbox where available, staged deployment and clear stop criteria can support innovation while protecting customers.

Challenges and limitations

Digital regulation faces several inherent difficulties. Technology evolves faster than legislation. Cross-border services can create conflicts of law and supervisory gaps. Small firms may struggle with the cost of compliance, while large platforms may possess superior data and bargaining power. Excessive data sharing can undermine privacy, but excessive restrictions can limit inclusion and competition. Fairness metrics may conflict, and explainability may be difficult for complex models. Human oversight can become symbolic if staff lack independence or expertise.

Regulation also has limits. It cannot guarantee that every fraud attempt will fail, every model will be fair, or every stablecoin will remain stable. Effective governance therefore combines law, supervision, institutional culture, technical controls, customer education and accessible redress.

Chapter Summary

Digital banking changes the delivery of financial services but does not remove traditional regulatory responsibilities. Mobile banking requires secure authentication, clear conduct, resilient infrastructure and effective fraud and AML controls. Open banking creates benefits through data portability while requiring disciplined consent, privacy, API security and clear liability. Embedded finance makes responsibility difficult to see, so licensing, outsourcing and customer-protection duties must be allocated explicitly.

Crypto-assets create risks involving custody, volatility, market integrity and financial crime. Stablecoins require careful analysis of redemption, reserve quality, liquidity and governance. CBDCs are central-bank liabilities whose design affects privacy, resilience, competition and financial stability.

AI regulation is concerned with the consequences of automated decisions. Model risk can arise from data, design, implementation, validation, use or change. Algorithmic fairness has multiple meanings and cannot be reduced to a single metric. Explainability must serve customers, managers and supervisors, while human oversight requires real authority and competence. A responsible-AI lifecycle includes inventory, purpose definition, data governance, independent validation, controlled deployment, monitoring and retirement. Across all technologies, the key principle is accountable innovation: the institution providing or sponsoring a financial service must understand its risks and ensure that customers have protection, transparency and redress.

Key Terms

Algorithmic bias: Systematic unfairness in an automated system’s data, design, operation or outcomes.

API: Application programming interface enabling software systems to communicate.

Cloud concentration risk: Risk arising from dependence on a small number of technology infrastructure providers.

Consumer duty: A regulatory expectation that firms deliver appropriate outcomes and fair treatment to customers.

Embedded finance: Provision of financial services within a non-financial platform or customer journey.

Explainability: The ability to communicate how and why an automated system produced an outcome.

Human-in-the-loop: A design in which a person participates in individual automated decisions.

Model risk: Risk of adverse consequences from errors or inappropriate use of a model.

Open banking: Authorized sharing of account data or payment initiation through standardized interfaces.

Operational resilience: Ability to continue important services within accepted disruption limits.

Precision: Of cases classified positive, the proportion that is actually positive.

Stablecoin: Crypto-asset designed to maintain a relatively stable value against a reference asset.

Substance over form: Regulatory assessment based on economic function rather than product label.

Third-party risk: Risk created by reliance on external providers or partners.

Tokenization: Digital representation of value or rights using a token system.

Transparency: Provision of understandable information about activities, risks, decisions and controls.

Validation: Independent assessment of whether a model is appropriate, accurate and properly controlled.

Review Questions

Short Answer Questions

Long Answer Questions

Analytical / Application Questions

Multiple Choice Questions with Answers

Question 1

Which principle requires regulators to focus on the economic function of a digital product rather than its marketing label?

Question 2

Which party normally remains accountable for lending conduct when a bank uses a fintech platform to distribute loans?

Question 3

Question 4

Question 5

Correct Answer: B. Ensuring specific, informed and controllable customer consent

Question 6

A stablecoin has eligible reserves of 900 million currency units and outstanding claims of 1 billion currency units. Using RCR = V_R ÷ V_C, what is its reserve coverage ratio?

Question 7

Which statement best describes effective human oversight of a high-impact AI system?

A. A person has authority, competence and information to challenge or stop the system

Correct Answer: A. A person has authority, competence and information to challenge or stop the system

Question 8

Which risk arises when a model is used outside the population or purpose for which it was validated?

Question 9

Why can removing a protected characteristic fail to eliminate algorithmic discrimination?

Correct Answer: B. Other variables may act as proxies for that characteristic

Question 10

B. Mapping critical dependencies and testing severe but plausible disruption scenarios

Correct Answer: B. Mapping critical dependencies and testing severe but plausible disruption scenarios

Chapter 13 Digital Banking, FinTech and Artificial Intelligence Regulation

Digital Banking, FinTech and Artificial Intelligence Regulation

Introduction and context