RegTech, SupTech and Technology Risk

Introduction

Banking regulation has entered a period in which compliance is increasingly designed, executed and supervised through technology. Digital transactions, cloud computing, application programming interfaces (APIs), biometric identification, artificial intelligence (AI) and automated reporting have changed both the nature of financial services and the methods used to control them.

RegTech refers to the use of technology by regulated financial institutions to meet regulatory, compliance and risk-management obligations. SupTech refers to the use of technology by supervisory authorities to monitor, analyse and enforce compliance. These technologies can reduce manual work, improve consistency and support earlier detection of suspicious activity. They can also introduce new risks: inaccurate data, opaque models, excessive dependence on vendors, cyberattacks, privacy violations and operational disruptions.

Technology therefore does not eliminate compliance risk. It changes its location and form. A bank may replace a manual review risk with a model risk, a paper-record risk with a data-integrity risk, or an in-house infrastructure risk with a cloud-concentration risk. Effective governance requires both technological capability and professional judgement.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the meaning and development of RegTech and SupTech.
2. Assess automated compliance, digital identity and electronic know-your-customer (e-KYC) systems.
3. Explain API-based regulatory reporting and the importance of data governance.
4. Evaluate cloud outsourcing, cybersecurity, operational resilience and third-party risk.
5. Identify validation, explainability, privacy and implementation limitations.
6. Apply a structured technology-risk framework to a banking case.

1. RegTech and SupTech: Concepts and Relationship

1.1 RegTech

RegTech is broader than compliance software. It includes the people, processes, data, controls and technologies used to satisfy regulatory requirements. Examples include:

• transaction-monitoring systems for anti-money-laundering (AML) compliance;
• sanctions-screening platforms;
• automated regulatory reporting;
• customer risk-scoring tools;
• digital recordkeeping and audit trails;
• policy-management systems;
• surveillance of employee communications and market conduct;
• identity verification and biometric authentication; and
• AI-assisted review of contracts, policies and regulatory changes.

The quality of RegTech depends on the complete control chain: regulatory interpretation, data collection, transformation, decision logic, human review, escalation, recordkeeping and assurance. An advanced tool cannot compensate for an incorrectly interpreted legal obligation or poor source data.

1.2 SupTech

SupTech is technology used by central banks, financial supervisors and resolution authorities. Supervisors may use it to:

• receive structured data from institutions;
• compare risk indicators across firms;
• identify unusual transaction or liquidity patterns;
• analyse complaints and market conduct;
• monitor capital, liquidity and concentration risks;
• conduct network analysis of financial relationships; and
• support risk-based examination and early intervention.

SupTech can change supervision from periodic, document-based inspection toward more continuous and data-driven monitoring. However, supervisory models face similar limitations to bank models: data may be incomplete, definitions may differ between institutions and statistical signals may be mistaken for legal violations.

1.3 The relationship between the two

RegTech and SupTech are interdependent. A supervisor may require banks to submit structured data, while banks must develop systems capable of producing reliable data. Poor reporting by institutions reduces the effectiveness of SupTech; unclear supervisory taxonomies increase the cost and ambiguity of RegTech implementation.

Figure: RegTech and SupTech form a connected regulatory information ecosystem.

2. Automated Compliance and Model Governance

Automation can perform repetitive checks quickly and consistently. A transaction-monitoring model, for example, may compare transactions with customer profiles, geographic indicators, sanctions lists and behavioural patterns. Automation is especially valuable where the obligation is rule-based, the data is structured and decisions can be reviewed.

Automation is less reliable where the obligation requires interpretation, contextual judgement or proportionality. A system may identify a transaction as unusual without establishing that it is criminal. It may also generate excessive false positives, causing investigators to overlook important cases. Conversely, overly permissive thresholds can create false negatives.

A sound automated-compliance control should include:

1. Purpose definition: the legal and business objective must be explicit.
2. Data inventory: sources, ownership, quality and permitted uses must be documented.
3. Decision logic: rules, thresholds, model versions and overrides must be recorded.
4. Testing: developers should test normal, unusual, borderline and adversarial cases.
5. Human oversight: material decisions should be reviewable by competent staff.
6. Monitoring: performance, drift, exceptions and error rates should be tracked.
7. Change control: changes must be approved, tested and auditable.
8. Independent validation: a party separate from development should assess fitness for purpose.

Validation and explainability

Validation asks whether a system is appropriate, accurate and stable for its intended use. It is not merely a technical test. It also considers legal interpretation, fairness, data representativeness, operational controls and the consequences of errors.

Explainability has at least three audiences. Customers may need a comprehensible reason for an adverse decision. Compliance officers need to understand why an alert was generated. Supervisors and auditors need evidence that the institution can govern the system. A complex model need not be reduced to an inaccurate simplistic explanation, but its inputs, logic, limitations and decision boundaries must be documented.

A useful distinction is between:

• global explainability, which describes how a model generally behaves; and
• local explainability, which explains a particular decision or alert.

Neither replaces accountability. A technically explainable model can still rely on unlawful or discriminatory variables, and an accurate model can still be inappropriate if customers cannot challenge its output.

3. Digital Identity and e-KYC

Digital identity is the process of establishing and using a person’s or organisation’s identity through electronic means. e-KYC applies digital methods to customer identification, verification, risk assessment and ongoing monitoring.

A typical e-KYC process includes:

1. collecting identity information and consent;
2. checking the authenticity of identity documents;
3. comparing a live image or biometric characteristic with the document or trusted identity record;
4. checking sanctions, politically exposed person and adverse-media sources where required;
5. assessing customer risk; and
6. maintaining records and updating information over time.

Digital identity can improve access and reduce onboarding time, especially for customers distant from branches. It can also reduce document forgery and create stronger audit trails. Nevertheless, it creates risks involving biometric data, identity theft, exclusion, spoofing, deepfakes, unreliable databases and unequal access to digital services.

Important control questions include:

• Is the identity source authoritative and current?
• What happens when a customer has no standard document?
• Are biometric systems tested across relevant populations?
• Can customers correct inaccurate data?
• Is there a non-digital or assisted alternative?
• How long are identity and biometric records retained?
• Are vendors prohibited from using customer data for unrelated purposes?

A risk-based approach is essential. Low-risk products may support simplified procedures where permitted by law, while higher-risk customers or transactions require enhanced due diligence. Risk-based does not mean arbitrary: criteria must be documented, consistently applied and subject to review.

4. API-Based Reporting and Data Governance

An API is a defined method through which one system requests or exchanges data with another. API-based regulatory reporting can replace manual spreadsheets with structured, more frequent and machine-readable submissions. It can support validation at the point of submission and reduce transcription errors.

However, automation can also industrialise errors. If a source system maps a liability incorrectly, an API may transmit the wrong figure rapidly and repeatedly. Consequently, regulatory reporting is a governance process, not simply a technical integration.

A strong reporting architecture includes:

• a regulatory data dictionary;
• common definitions and taxonomies;
• data lineage from source to report;
• reconciliation to the general ledger and risk systems where relevant;
• validation rules and exception queues;
• access controls and encryption;
• submission acknowledgements and immutable audit trails; and
• named accountability for data owners and report approvers.

Data quality is commonly assessed through dimensions such as accuracy, completeness, timeliness, consistency, validity and uniqueness. These dimensions may conflict. A complete dataset can still be inaccurate; timely data can still be insufficiently validated.

A bank should distinguish the system of record from a reporting transformation layer. Every transformation should be documented, including aggregation, currency conversion, filtering, imputation and classification. Where estimates are used, the institution should record the method, assumptions and approval.

5. Cloud Outsourcing and Third-Party Risk

Cloud services provide computing, storage, software and security capabilities on demand. They may improve scalability and reduce infrastructure costs, but they also create dependency on service providers and telecommunications networks.

Common service models are:

The division of responsibility varies by contract and provider. A bank remains responsible for complying with law even when a cloud provider performs technical functions. Outsourcing does not outsource accountability.

Third-party due diligence should assess financial strength, security architecture, resilience, subcontractors, location of data, regulatory access, incident reporting, recovery capability, audit rights and exit arrangements. Contracts should address service levels, data ownership, confidentiality, deletion, portability, business continuity and termination assistance.

A major concern is concentration risk. Several banks may depend on the same cloud provider, identity service, payment processor or telecommunications network. An outage at one provider can therefore have systemic consequences. Supervisors increasingly examine critical third parties and important business services rather than focusing only on individual contracts.

6. Cybersecurity and Operational Resilience

Cybersecurity protects confidentiality, integrity and availability. These objectives are often called the CIA triad:

• Confidentiality: information is accessible only to authorised persons.
• Integrity: information and systems are accurate and protected from unauthorised alteration.
• Availability: services and information are accessible when needed.

Banking threats include credential theft, ransomware, distributed denial-of-service attacks, malware, insider abuse, supply-chain compromise, social engineering and exploitation of unpatched vulnerabilities. Controls should be layered rather than dependent on a single perimeter.

Important measures include multi-factor authentication, least-privilege access, network segmentation, secure software development, vulnerability management, encryption, tested backups, security monitoring, staff training and incident-response exercises. Critical controls should be tested under realistic conditions, including scenarios in which a key vendor is unavailable.

Operational resilience is broader than cybersecurity. It concerns the ability to continue important business services within acceptable limits during disruption and to recover safely. A resilience programme normally identifies:

1. important business services;
2. supporting processes, people, facilities, technology and third parties;
3. impact tolerances;
4. dependencies and vulnerabilities;
5. preventive and adaptive controls; and
6. response, recovery and lessons-learned arrangements.

The distinction between recovery time objective (RTO) and recovery point objective (RPO) is important. RTO is the target time for restoring a service after disruption. RPO is the maximum acceptable period of data loss measured backward from the disruption. For example, an RPO of 15 minutes means that backup or replication arrangements should limit potential data loss to approximately 15 minutes, subject to system design and testing.

Resilience claims must be demonstrated. A written plan is not evidence that recovery will work. Banks should conduct failover tests, scenario exercises, communications tests and independent reviews, while avoiding tests that create unacceptable risks to live customers.

7. Privacy, Ethics and Regulatory Accountability

Technology risk is also a rights and governance issue. Financial institutions process identity, transaction, location, biometric and behavioural information. Relevant principles commonly include purpose limitation, data minimisation, accuracy, retention control, security, transparency and lawful processing. Exact legal requirements vary by jurisdiction, but responsible governance is universal.

Ethical issues arise when automated systems exclude customers, reproduce historical bias or use opaque proxies for protected characteristics. For example, a model that uses geographic or device variables may indirectly disadvantage particular communities. Fairness testing should therefore consider both inputs and outcomes, while recognising that no single fairness metric resolves every legal or social question.

Customers should have appropriate notice, channels for correction and meaningful escalation. Human review should be available where automated decisions have significant consequences, subject to applicable law. Boards and senior management must understand material technology risks; they cannot delegate accountability merely because a system was purchased from a reputable vendor.

8. A Practical Technology-Risk Governance Framework

A bank can organise its approach around six mutually reinforcing layers:

1. Governance: board oversight, accountability, risk appetite and independent challenge.
2. Inventory: register systems, models, data assets, vendors and critical services.
3. Assessment: evaluate legal, operational, cyber, privacy, model and concentration risks.
4. Control: apply preventive, detective and corrective safeguards.
5. Assurance: conduct validation, audit, penetration testing, exercises and reviews.
6. Learning: record incidents, near misses, complaints and control improvements.

A technology-risk register should identify the asset, owner, purpose, dependencies, risk scenarios, controls, residual risk, monitoring indicators and review date. Indicators may include unresolved high-severity vulnerabilities, failed reconciliations, excessive false-positive alerts, vendor incidents, recovery-test failures, privileged-access exceptions and stale customer information.

Risk assessment should consider both probability and impact, but a simple score must not disguise uncertainty. A low-probability event with severe consequences may require stronger controls than a frequent but minor event. Scenarios should include correlated failures, such as a cloud outage occurring during a cyberattack or reporting deadline.

9. Illustrative Case: Meridian Bank’s Digital Onboarding Programme

Background

Meridian Bank, a fictional regional bank, launched a mobile account-opening service. It used document recognition, facial comparison, sanctions screening and an external cloud provider. Customer applications were approved in minutes, and the bank planned to expand the service to small-business accounts.

Problem

After six months, complaints increased. Some legitimate customers were rejected because image quality was poor or their names did not match database formats. Investigators also found that a vendor update changed alert volumes without a documented impact assessment. A cloud outage interrupted onboarding and delayed access to customer records. Management initially treated each issue as a separate technical problem.

Analysis

The bank’s review identified four connected weaknesses:

• the identity model had not been tested adequately across customer populations;
• data ownership and correction procedures were unclear;
• the vendor contract contained limited audit and exit provisions; and
• operational-resilience testing focused on the bank’s own systems, not the complete service chain.

The bank also relied on a single approval metric: the percentage of applications completed automatically. That metric rewarded speed but did not measure accuracy, exclusion, false positives, customer complaints or manual-review quality.

Approach and solution

Meridian established a cross-functional committee involving compliance, information security, operations, legal, data governance and customer-service teams. It created a system inventory and mapped the complete customer journey. The bank then:

1. introduced assisted verification for customers unable to complete biometric checks;
2. tested error rates across different devices, lighting conditions and customer groups;
3. required documented approval for vendor model changes;
4. implemented data lineage and correction procedures;
5. added contractual rights concerning audit, incident notification, subcontracting and exit support;
6. established manual-review service levels; and
7. tested onboarding during cloud and telecommunications disruptions.

The bank changed its performance dashboard to include completion time, rejection reasons, false-positive rates, complaint volumes, manual-review outcomes, service availability and unresolved control exceptions.

Outcome

The programme became slower for a small proportion of applicants but more reliable overall. Complaints declined, investigators gained clearer evidence for decisions and management became able to distinguish vendor error from customer fraud. The bank also discovered that its continuity plan depended on an identity-data service not included in the original resilience analysis.

Learning points

The case illustrates that digital transformation is a control-system redesign, not merely a software implementation. Speed is not equivalent to compliance effectiveness. Human alternatives, data governance, vendor oversight and realistic resilience testing are essential. Most importantly, the bank’s accountability remained intact even though several functions were automated or outsourced.

10. Contemporary Developments and Best Practices

Generative AI, privacy-enhancing technologies, digital currencies, open banking and increasingly standardised reporting are shaping the next phase of financial regulation. Generative AI may assist with regulatory change analysis or document classification, but it can produce confident inaccuracies, disclose confidential information or create unverifiable reasoning. Its use should be limited by approved purposes, data controls, testing, human review and records of generated outputs.

Open banking and API ecosystems increase customer choice but expand the attack surface and dependency network. Consent management, authentication, liability allocation and third-party oversight are central controls. Privacy-enhancing technologies, such as tokenisation and carefully designed cryptographic methods, may reduce exposure but do not remove the need for governance.

Good practice can be summarised as follows:

• begin with regulatory purpose and customer impact, not with a fashionable technology;
• maintain an authoritative inventory of systems, models, data and vendors;
• use risk-based but documented controls;
• validate models before deployment and monitor them after deployment;
• preserve human review and appeal routes for material decisions;
• make data lineage and accountability visible;
• test the whole service chain, including critical third parties;
• rehearse cyber and operational disruptions;
• maintain tested exit and substitution plans; and
• report limitations and incidents honestly to senior management and supervisors.

Chapter Summary

RegTech uses technology to support institutional compliance, while SupTech enables supervisory authorities to analyse information and conduct more continuous, data-driven oversight. Both depend on reliable data, clear taxonomies and accountable governance.

Automated compliance can improve speed and consistency but introduces model, data, explainability and false-positive risks. Digital identity and e-KYC can expand access and strengthen verification, yet require privacy safeguards, inclusion measures, biometric testing and correction mechanisms. API-based reporting improves structured exchange but must be supported by data lineage, reconciliation and ownership.

Cloud outsourcing provides scale and specialised capability, but banks remain accountable for legal compliance and must manage concentration, subcontracting, exit and resilience risks. Cybersecurity protects confidentiality, integrity and availability; operational resilience focuses on maintaining important services through disruption. Effective technology-risk management combines governance, inventory, assessment, control, assurance and learning.

The central professional lesson is that technology is neither inherently compliant nor inherently risky. Its effects depend on design, data, controls, human judgement, vendor relationships and continuous validation.

Key Terms

RegTech: Technology used by financial institutions to meet regulatory and compliance obligations.

SupTech: Technology used by supervisory authorities to monitor and oversee financial institutions.

e-KYC: Electronic processes for identifying and verifying customers and assessing their risk.

Digital identity: An electronically represented and verified identity used to access services.

API: A defined interface that enables systems to exchange data or request functions.

Data lineage: The documented path of data from its origin through transformations to its final use.

Model risk: The risk that a model is unsuitable, incorrectly implemented or improperly used.

Explainability: The ability to communicate how a system or model produces an output.

False positive: An alert or rejection incorrectly identifying legitimate activity as problematic.

False negative: A failure to identify activity that should have been detected.

Cloud computing: On-demand access to shared computing resources and services.

Outsourcing: Contracting a function or service to an external provider.

Third-party risk: Risk arising from dependence on external organisations or service providers.

Concentration risk: Risk created by excessive dependence on one provider, technology or location.

Cybersecurity: Protection of information and systems against unauthorised or harmful activity.

Operational resilience: The ability to continue important services during disruption.

RTO: Target time for restoring a service after a disruption.

RPO: Maximum acceptable period of data loss measured backward from a disruption.

Data governance: Structures and processes governing data quality, ownership, access and use.

Technology risk: Risk arising from technology design, operation, failure, misuse or dependence.

Review Questions

Short Answer Questions

1. Distinguish between RegTech and SupTech.
2. Why does automation not eliminate compliance risk?
3. What is the purpose of data lineage in regulatory reporting?
4. Distinguish between RTO and RPO.
5. Why does outsourcing not transfer a bank’s accountability?

Long Answer Questions

1. Explain the principal benefits and limitations of automated AML and sanctions-screening systems.
2. Discuss the governance requirements for digital identity and e-KYC.
3. Analyse the relationship between API-based reporting and data quality.
4. Explain how cloud outsourcing can create operational and concentration risk.
5. Compare cybersecurity with operational resilience and show why a bank requires both.

Analytical / Application Questions

1. A bank’s automated onboarding system rejects a higher proportion of customers from rural areas because identity images are frequently unclear. Design an investigation and remediation plan.
2. A critical cloud provider suffers a 12-hour outage during a regulatory reporting deadline. Identify the bank’s immediate actions, governance failures to investigate and longer-term resilience improvements.
3. A transaction-monitoring model produces a 70% increase in alerts after a vendor update. Explain how compliance, data, model-validation and senior-management teams should respond.

Multiple Choice Questions with Answers

Question 1

Which statement best describes RegTech?

A. Technology used only by central banks for monetary policy

B. Technology used by regulated institutions to meet compliance obligations

C. A method of replacing all compliance employees with software

D. A legal framework governing cloud providers

Correct Answer: B. Technology used by regulated institutions to meet compliance obligations

Question 2

What is a principal purpose of SupTech?

A. To market banking products to customers

B. To provide personal financial advice

C. To support supervisory monitoring and analysis

D. To eliminate regulatory reporting

Correct Answer: C. To support supervisory monitoring and analysis

Question 3

Which control is most directly associated with data lineage?

A. Tracking data from its source through transformations to a report

B. Increasing the number of customer advertisements

C. Removing all manual review

D. Allowing unrestricted vendor access

Correct Answer: A. Tracking data from its source through transformations to a report

Question 4

What does an RPO measure?

A. The target time for restoring a service

B. The maximum acceptable period of potential data loss

C. The number of recovery staff required

D. The maximum number of cloud providers permitted

Correct Answer: B. The maximum acceptable period of potential data loss

Question 5

Why is human oversight important in automated compliance?

A. Automated systems cannot process any structured data

B. Human review can provide context and challenge questionable outputs

C. Regulators prohibit all forms of automation

D. Human review guarantees that errors never occur

Correct Answer: B. Human review can provide context and challenge questionable outputs

Question 6

Which is an example of concentration risk?

A. Using two independent approval officers

B. Maintaining a documented data dictionary

C. Relying on one cloud provider for several critical services

D. Testing a backup system

Correct Answer: C. Relying on one cloud provider for several critical services

Question 7

Which option is part of the CIA triad of cybersecurity?

A. Profitability

B. Confidentiality

C. Market share

D. Product innovation

Correct Answer: B. Confidentiality

Question 8

What is a key limitation of biometric e-KYC?

A. It can never create an audit trail

B. It may create privacy, spoofing or exclusion risks

C. It cannot be used with identity documents

D. It removes the need for ongoing monitoring

Correct Answer: B. It may create privacy, spoofing or exclusion risks

Question 9

Which statement about outsourcing is correct?

A. Outsourcing transfers all regulatory accountability to the vendor

B. A bank remains accountable for outsourced activities

C. Outsourced services do not require contracts

D. Third-party risk exists only when a vendor is foreign

Correct Answer: B. A bank remains accountable for outsourced activities

Question 10

What should a bank do after a major vendor model update changes alert volumes?

A. Ignore the change if the vendor approved it

B. Delete prior alerts to maintain consistency

C. Conduct impact assessment, validation and documented change control

D. Disable all transaction monitoring permanently

Correct Answer: C. Conduct impact assessment, validation and documented change control