Module 15 | Global Financial Crimes, Risk, and RegTech Library

Research verification date: 9 August 2026
Important notice: Educational material only; not legal advice. It does not determine obligations in any jurisdiction or replace legal counsel, regulator engagement, institution-specific risk assessment, or a documented decision.

Source Quality and Currency Note

This module uses primary sources first: international standard setters, statutes and regulations, financial-intelligence and supervisory authorities, official technical guidance, public enforcement releases, consent orders, and court or government materials. Time-sensitive statements were verified on 9 August 2026. Requirements, implementation dates, supervisory priorities, vendor features, and individual enforcement proceedings can change. The module distinguishes legal or regulatory requirements from supervisory expectations, observed enforcement themes, and the library's operating recommendations. Dedicated jurisdictional modules provide the local legal analysis that this thematic module cannot replace.

Primary Source Map

The source identifiers used throughout the module point to complete MLA 9 entries at the end. This map makes the primary evidence base explicit before substantive reading:

• [S01] Financial Action Task Force: The FATF Recommendations.
• [S02] Financial Action Task Force: Opportunities and Challenges of New Technologies for AML/CFT.
• [S03] Basel Committee on Banking Supervision: Principles for Effective Risk Data Aggregation and Risk Reporting (BCBS 239).
• [S04] Office of the Comptroller of the Currency: Interagency Guidance on Third-Party Relationships: Risk Management.
• [S05] European Union: Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector.
• [S06] European Commission: Digital Operational Resilience Act (DORA).
• [S07] Financial Conduct Authority: Operational Resilience.
• [S08] Monetary Authority of Singapore: Technology Risk Management Guidelines.
• [S09] National Institute of Standards and Technology: The NIST Cybersecurity Framework (CSF) 2.0.
• [S10] Financial Crimes Enforcement Network: FinCEN Assesses $1.3 Billion Penalty Against TD Bank for Widespread and Systemic Violations of Bank Secrecy Act.
• [S11] Financial Conduct Authority: FCA Fines Starling Bank for Failings in Financial Crime Systems and Controls.
• [S12] Australian Transaction Reports and Analysis Centre: AUSTRAC Commences Civil Penalty Proceedings Against Westpac.
• [S13] Federal Financial Institutions Examination Council: Bank Secrecy Act/Anti-Money Laundering Examination Manual.
• [S14] European Banking Authority: Guidelines on the Role and Responsibilities of AML/CFT Compliance Officers.

How to Use This Module

• Enterprise leader pass: executive thesis, decision models, Global Core / Local Edge architecture, maturity profile, failure cascade, and executive discussion questions.
• Operator pass: process design, decision rights, data/evidence outputs, workflow handoffs, performance measures, technology and governance dependencies, and checklists.
• Specialist pass: regulatory mechanics, technical and control objects, architecture, analytical boundaries, test methods, assurance evidence, and glossary.

Learning Objectives

• Translate a financial-crime program into a control-stack architecture spanning authoritative data, enrichment, screening and monitoring, investigation, decisioning, action, reporting, evidence, and assurance.
• Distinguish a business capability, control objective, technology component, implementation partner, managed service, data provider, model provider, and critical third party so accountability is not transferred by a contract label.
• Design build, buy, configure, integrate, and retire decisions around control effectiveness, data permissions, population coverage, auditability, resilience, cost, concentration, and exit rather than feature demonstrations alone.
• Use third-party, operational-resilience, cyber, risk-data, and AML/CFT guidance to create an executable supplier-governance and change-control model.
• Make Global Core / Local Edge architecture choices that standardize reusable capability and evidence while preserving local legal interpretation, data constraints, reporting, and accountable action.
• Test outages, stale data, missed interfaces, access failures, rule/model changes, vendor degradation, queue overload, and manual fallback as control scenarios rather than merely IT incidents.

Key Terms Used Deliberately

Control stack. The connected people, process, data, technology, policy, and evidence components that together achieve and demonstrate a financial-crime control objective.

Authoritative source. The system or record designated as the reliable origin for a fact, status, identity, decision, or action within a stated purpose and time.

System of record. The controlled repository that retains the official workflow, determination, status, or evidence for a defined business or control object.

Critical third party. A supplier or dependency whose failure, compromise, or material change could impair a material service, control, legal obligation, or customer outcome.

Configuration debt. Accumulated rules, parameters, interfaces, overrides, local exceptions, and undocumented workarounds that increase change and assurance risk.

Fallback. A pre-designed and tested alternate process or capability that preserves the required control outcome when a component or supplier is unavailable or unsafe.

The Questions This Module Answers

1. Which control outcomes—not products, dashboards, or vendors—must the architecture deliver for every legal entity and market?
2. Where is the authoritative identity, customer, account, transaction, counterparty, decision, action, and evidence record, and how is each reconciled?
3. Which integrations can silently exclude a population, duplicate activity, alter an alert, overwrite a disposition, or break the audit trail?
4. Which service, data, cloud, model, workflow, or implementation partner is critical to a control, and who remains accountable when it fails?
5. Can a material decision be replayed from the actual source data, configuration, version, analyst evidence, approval, and action that existed at the time?
6. What product, market, data-localization, language, threshold, reporting, or customer-treatment requirements genuinely require Local Edge rather than ungoverned fragmentation?
7. How long can a material control operate in degraded mode, what must be stopped, and how will the enterprise prove population coverage and remediation afterward?

1.1 An architecture is a control map, not an application inventory

The enterprise should begin with the financial-crime outcomes it must achieve: know the customer and beneficial owner; screen relevant parties and activity; detect and investigate unusual or prohibited behavior; make lawful and timely decisions; file or provide reports where required; protect customers; preserve evidence; and demonstrate that the full intended population was controlled. Each outcome crosses systems and teams. Customer and account systems establish part of the identity record. Payment, trading, card, wallet, and channel systems create events. Data-quality and enrichment services add context. Rules, models, and list providers generate signals. Workflow routes work. Investigators validate evidence. Operations enact holds, exits, filings, or communications. Evidence repositories, reporting tools, and management information make the result reviewable.

A technical diagram that shows arrows between products is not yet a control map. The control map must state the authoritative object, owner, permitted use, system of record, timing expectation, applicable legal entities, reconciliation, failure action, and evidence location for each handoff. For example, a sanctions-screening service may receive a customer name from onboarding, a payment message from a payments gateway, and a list update from a provider. The enterprise needs to know which names, identifiers, and transaction messages are in scope; whether the interface can drop or delay records; which version of the list and matching logic applied; who reviews a possible match; how a hold is placed; and where the decision and release evidence reside. The word "integrated" is not proof that those answers exist.

BCBS 239 is a useful lens even beyond prudential risk reporting: risk information needs governance, accuracy and integrity, completeness, timeliness, adaptability, and clear reporting. The financial-crime translation is to reconcile populations at control boundaries and to report control exceptions as risk, not as a technology metric. A screen that runs quickly against an incomplete source population is not an effective screen. [S03][S13][S14]

1.2 Enterprise accountability remains with the institution

Third-party risk governance begins before contracting and continues through exit. The sponsoring executive and accountable control owner must be able to articulate the service's role in the control, the harm if it fails or changes, the institution's data and legal exposure, the measures of acceptable performance, and the conditions under which the service must be suspended. The commercial owner, technology owner, security, privacy, procurement, legal, resilience, and financial-crime teams contribute evidence; none is a substitute for an accountable business decision.

The 2023 U.S. interagency guidance frames third-party relationships as a lifecycle: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination. DORA adds explicit attention to ICT risk and third-party arrangements in its European legal context. The details and legal scope differ, but the enterprise design implication is stable: a critical supplier needs an owner, an inventory, a service description, due diligence, enforceable information and audit rights where appropriate, security and confidentiality terms, subcontractor visibility, change notification, performance reporting, incident and exit obligations, and tested contingency arrangements. A generic vendor score is inadequate if it cannot show how the specific financial-crime control is protected. [S04][S05][S06]

TD Bank and Starling illustrate why the institution cannot use systems change or growth as an excuse for poor control outcomes. The enforcement materials are not technology-architecture mandates, but they are an operational warning: control design must match volume, channel, product, and market reality, with sufficient coverage, governance, escalation, and remediation. A new platform, a managed service, or a data provider may expose existing debt; it does not extinguish it. [S10][S11]

2.1 Separate source facts, derived signals, decisions, and evidence

The most reliable operating stacks keep four categories visible. First are source facts: customer-provided information, account records, payment messages, device events, official lists, documents, and locally authoritative records. Second are derived signals: normalized fields, entity links, risk scores, watchlist candidates, transaction features, external intelligence, and model outputs. Third are decisions and actions: a reviewer disposition, a risk-rating change, a hold, a request for information, a report, a closure, or an escalation. Fourth is evidence: the source snapshot, data-quality state, configuration and versions, analysis, authority, approval, execution confirmation, and post-action outcome. A system can store more than one category, but it should not blur them.

Blurring causes preventable failure. A vendor label can become a fact in a customer record even when it is an inference. An alert disposition can be overwritten by a downstream workflow and make the rationale unrecoverable. A transaction feed can be normalized without retaining the original message or a reconciliation that proves completeness. A case-management platform can show a final status while the action system has failed to place the intended restriction. The design must retain link keys, timestamps, source system, effective dates, confidence or limitation, and ownership across these transitions. An investigator should be able to identify what was known at the time, not reconstruct the decision from today's altered data.

Data contracts make the requirement executable. Each upstream and downstream interface should name fields, format, permissible values, sensitivity, required/optional status, update cadence, late or corrective records, quality thresholds, error handling, owner, and reconciliation. A financial-crime team should have a daily or defined-period population proof: events expected, received, rejected, duplicated, delayed, out of scope, pending remediation, and reconciled. The proof must cover manual uploads and vendor feeds as well as APIs. [S03][S09][S13]

2.2 Workflow, human capacity, and action channels are architecture

Financial-crime architecture fails when it optimizes signal generation but not the work needed to decide and act. An alert cannot become a control outcome without case allocation, evidence gathering, a trained reviewer, escalation, approval where required, action execution, and feedback. Capacity, skills, queues, service levels, and user experience are therefore architectural properties. A system that produces a high-priority queue faster than it can be reviewed creates a delayed-control risk. A review screen that hides source evidence or forces analysts to navigate disconnected tools creates quality and consistency risk. A workflow that cannot distinguish candidate intelligence from verified fact creates customer-treatment and reporting risk.

The operating design should express specific handoffs. It should identify the case owner, business owner, decision authority, reviewer or approver, and executor for each material action. It should show how cases move across investigation, fraud, sanctions, customer operations, legal, reporting, and law enforcement liaison teams without losing evidence or target dates. It should capture the reason for reassignment, pause, escalation, override, closure, and reopening. It should control emergency access and override as carefully as normal processing, because crisis-mode work may involve the highest customer, regulatory, and sanctions stakes.

An action channel also needs confirmation. A case status of "hold requested" is not equivalent to a payment block, account restriction, report submission, or notification being executed. Interfaces to core banking, payment hubs, card processors, exchanges, communication tools, and regulator portals should return a clear acknowledgement and exception. These acknowledgements should be visible to the case and reconciled. Otherwise management metrics can report completed controls while the intended action never occurred. [S01][S03][S13][S14]

3.1 Choose capabilities by control fit, not demo quality

A procurement process often begins with features: screening coverage, alert workflow, graph analytics, AI assistance, dashboards, integration speed, or cost. Those factors matter, but a financial-crime decision should begin with control fit. What precise population and risk must the component help control? What legal entities, markets, products, asset classes, languages, and data classes are in scope? Does the component generate information, prioritize work, recommend an action, execute a bounded action, or retain the official record? What must remain in-house to preserve accountability? What evidence does the component provide, and can it be exported and replayed?

A build decision can be justified where the enterprise needs differentiated local logic, deep integration, unique data, strategic ownership, or tighter evidence control. A buy decision can be justified where a provider offers mature commodity capability, maintained regulatory content, scale, and faster implementation. A managed service can be justified where it brings specialized operating capacity. None of these labels predicts control quality. Custom code can become unsupported; packaged software can become a black box; managed services can detach the institution from evidence and decision authority. The choice should be made through the same dossier: objective, scope, data, action boundary, controls, performance, resilience, security, cost, implementation effort, local variation, oversight, and exit.

The evidence requirement should be contractual and technical. For a screening or data provider, it may include source provenance, update cadence, matching logic, list/version history, API request/response logs, availability metrics, data-location commitments, incident notifications, and audit support. For a workflow or analytics provider, it may include configuration export, rule/model version, user activity, role and permission record, queue metrics, system logs, test evidence, defect history, and retention/export capability. If the enterprise cannot obtain or recreate the evidence needed to explain its control, it has accepted a material assurance gap. [S02][S04][S09]

3.2 Third-party governance must include change, concentration, and exit

Due diligence cannot be a one-time questionnaire. The enterprise must monitor whether the service still operates within its approved boundary. Material changes may include a new cloud region, subcontractor, data source, model, matching algorithm, product feature, pricing model that changes use, authentication method, support location, legal entity, ownership structure, or incident response process. Any of these may affect data permissions, availability, evidence, local legal obligations, or control outcomes. A robust change clause is useful only when the receiving organization has an owner who can assess and approve the change before it affects a material control.

Concentration deserves separate treatment. Multiple apparently independent applications can rely on the same cloud provider, identity service, enrichment provider, payments hub, implementation partner, or small group of specialists. A single common dependency may therefore disrupt KYC, sanctions, transaction monitoring, fraud, cases, and reporting at once. The impact analysis should identify common-mode failure, not merely direct vendor names. It should define tolerances for important control services, recovery-time and recovery-point objectives, manual-processing limits, degradation policy, communications, regulatory notification triggers, and evidence reconciliation after restoration. FCA operational-resilience expectations and DORA provide useful formal lenses where applicable; their broader lesson is to test severe-but-plausible disruption rather than rely on supplier assurances. [S05][S06][S07][S08]

Exit is an operational capability, not an end-of-contract paragraph. The enterprise needs readable data extracts, configuration and rule history, evidence retention, transition support, replacement interfaces, trained people, intellectual-property and licensing clarity, and a plan for the period when old and new controls coexist. It should test a partial exit or portable recovery before the relationship is in distress. A supplier that cannot support evidence export, parallel run, controlled migration, or an alternate operating process is a source of lock-in and control fragility.

4.1 Treat configuration as controlled policy execution

Much of the effective control stack is configuration rather than code: risk factors, match thresholds, customer segments, product flags, routing rules, alert severity, timer settings, report templates, local lexicons, user roles, exception logic, and retention categories. These settings can be as consequential as a policy change, yet they are often managed through dispersed administrative access or project workarounds. Configuration debt grows when local exceptions are necessary but not documented, when overrides bypass the release gate, when the same business rule is expressed differently across tools, or when no one can connect a parameter to its approved rationale and testing.

A controlled configuration model has an inventory, owner, purpose, legal-entity and market scope, decision impact, source/policy basis, version, effective date, approval, test evidence, dependencies, rollback path, and monitoring. It distinguishes global baseline, mandatory local overlay, permitted local option, temporary exception, and obsolete configuration awaiting retirement. It supports a reproducible promotion path from development through test and production; it restricts direct production change; and it logs emergency changes with retrospective review. The goal is not to slow prudent adjustment. It is to prevent a silent parameter change from changing a customer's outcome or excluding a population without accountability.

Release governance must include business and control acceptance, not only technical deployment. Testing should include source-data scenarios, false/true candidate behavior, workload, cutover, permissions, downtime, late data, duplicate data, recovery, report submission, adverse customer effects, and local legal constraints. A release should have named owners for data, control logic, workflow, action channel, reporting, technology, and business risk. The evidence pack should allow an independent reviewer to see exactly what changed and whether the intended control still works. [S03][S04][S09][S13]

4.2 Security and operational resilience protect control effectiveness

Financial-crime technology holds sensitive identity, transaction, investigative, sanctions, law-enforcement, and reporting information. Security controls are therefore not only confidentiality requirements; they protect the integrity and availability of the control. Unauthorized access can reveal investigations or enable evasion. A compromised data feed can suppress or manipulate alerts. A ransomware event can interrupt reporting and action. An overly broad service account can allow an automation or vendor to alter outcomes without proper approval. NIST CSF 2.0 provides a useful governance and risk-management vocabulary, while local regulatory requirements define additional obligations. [S09]

The architecture should implement least privilege, segregation of duties, strong authentication, privileged-access review, service identity control, secrets management, encryption, logging, vulnerability and patch management, secure development, supplier access restrictions, and incident response. It should protect integrity with immutable or controlled logs, record-level lineage, reconciliation, versioning, tamper-evident evidence where appropriate, and clear ownership of data correction. It should protect availability with service objectives, capacity planning, backups, recovery, redundant paths where proportionate, manual workarounds, and tested restoration. None should be asserted at policy level only: the control team needs evidence that it works for the actual systems and vendors in scope.

Resilience testing should be framed as financial-crime scenarios. Can the organization screen urgent payments if the primary service is unavailable? Can it detect and reconcile a missed data interval after recovery? Can investigators access required evidence during an identity-provider outage? Can a suspicious-activity report be completed and submitted if a case-management platform is down? Can the enterprise halt unsafe automated actions while continuing urgent manual controls? These questions convert technical resilience into customer, regulatory, and control outcomes. [S05][S06][S07][S08]

5.1 Global Core should be reusable, observable, and evidence-bearing

Global Core is the part of the stack that benefits from common design: canonical object models; identity and data contracts; security and access patterns; a shared control taxonomy; list and typology management; workflow primitives; investigation evidence standards; logging; versioning; release gates; metrics; vendor governance; and enterprise resilience patterns. Centralizing these components can reduce duplication, make quality and coverage comparable, support group oversight, and enable a regulator-ready evidence trail. It can also lower the cost of delivering improvements across markets.

The global platform should expose local configuration through controlled mechanisms rather than force local teams to invent independent systems. It should make local overlays visible, versioned, tested, and reportable. It should retain enough detail to show which global version and which local rule or policy applied to a particular decision. It should offer reliable interfaces and documentation, but it should not assume that every market can share every data element or decision. A global customer-risk taxonomy may be shared, while legal thresholds, language, documentary evidence, retention, reporting, action authority, and personal-data restrictions differ.

The governance test is whether the Global Core can create common evidence without obscuring Local Edge accountability. A group dashboard that aggregates cases but cannot identify local scope, local legal owner, local data restrictions, or local exceptions creates false comfort. A standardized platform that lets a market bypass controls without documented approval creates hidden fragmentation. The mature design enables comparison and challenge while preserving legal and operational truth. [S01][S03][S04][S14]

5.2 Local Edge is an accountable adaptation, not a parallel stack

Local Edge should exist where a market has a distinct legal perimeter, data use restriction, regulator reporting format, language or script requirement, product process, payment rail, customer communication obligation, or accountable decision owner. The local design should document why the variation is required, what global capability it uses, what fields or rules differ, who approves it, how it is tested, how it reports to group, and when it will be reviewed. This prevents both extremes: unworkable centralization that ignores the law, and uncontrolled local customization that makes group oversight impossible.

Local teams should be involved early in product, vendor, data, and release decisions. A central vendor contract may support global use, but a local entity still needs to confirm data transfer, outsourcing, record-keeping, consumer, sanctions, and reporting consequences. A global data model may accommodate a local field, but the market needs to determine whether it may be collected, stored, processed, or transmitted for the proposed purpose. A global rule pack may be useful, but the market must own its local threshold and action evidence. The architecture creates the capacity to do this; it cannot make the legal decision by itself.

A valuable quarterly review compares the intended global standard, local overlays, actual configurations, population reconciliation, incidents, vendor changes, open issues, and evidence from a sample of decisions. It asks whether a local variation remains necessary, whether it should be promoted to global capability, and whether a global change has created unintended local risk. This is how a platform becomes a governed operating model rather than a central IT program.

6.1 Measure control health, not platform activity

Dashboarding is useful only when it informs a control decision. Login counts, alerts created, tickets closed, API calls, deployment frequency, or vendor uptime can be useful diagnostic metrics. They do not prove that the intended population was controlled or that action was appropriate. A control-health view should connect business scope, data completeness, source latency, rules/models and versions, alert or case flow, aging, analyst quality, decision consistency, action success, report timeliness, customer impact, exceptions, outages, vendor performance, local overlays, and open issues.

Metrics need denominators and segmentation. A sudden decline in alerts may reflect less risk, a source outage, a broken interface, a changed threshold, a delayed list update, customer migration, or a queue filter. A high closure rate may reflect effective triage or inadequate investigation. A good report therefore presents expected versus received population, intervention points, false/true outcomes where measurable, aged work by risk, action acknowledgement, changes in configuration, data-quality exceptions, and evidence of remediation. It should distinguish known exclusions from untested gaps.

The performance pack should be reviewed by those able to act: technology can resolve an interface; the control owner can alter a process; a product owner can change a journey; risk can challenge residual acceptance; local management can address market constraints; and senior management can allocate funding or pause a launch. If all issues become technology tickets, the program loses ownership. [S03][S10][S11][S13]

6.2 Sustainable remediation requires architectural root cause

When an issue is discovered, the immediate fix may be necessary: restore a feed, pause an unsafe rule, add reviewers, correct an access role, submit a late report, or contact a supplier. Sustainable remediation goes further. It asks which control object, ownership boundary, data contract, release practice, capacity assumption, contract term, monitoring metric, or governance decision allowed the issue to persist. It tests the remedy across the affected historic population and future change path. It retains evidence that management knew the scope, chose a remedy, and verified the outcome.

A remediation plan should define the issue statement and impact; legal entities, products, dates, and populations; immediate containment; root-cause hypotheses; dependencies; accountable owner; milestones; evidence required for closure; validation method; residual risk; communications; and recurrence monitoring. A plan that says implement new system is incomplete unless it specifies which control objective is restored, how historical records are handled, what the interim control is, how the new stack is tested, and who certifies that it works. A platform migration itself can be the source of new gaps and should be governed as a high-risk change.

The final test is operational truth: can an independent reviewer select a material customer, transaction, alert, incident, or change and trace the system from source to action and back? Can the team demonstrate the scope of an outage or defect, the affected population, the manual workaround, the reconciliation, the decision to close the issue, and the monitoring that prevents recurrence? If not, technology modernization has not yet become a sustainable control capability.

Common Misconceptions and Contrarian Insights

• A platform is a control: A platform is a component; the control includes scope, data, logic, workflow, decision, action, evidence, and assurance.
• Outsourcing transfers accountability: A contract can allocate activities and evidence rights, but the institution remains accountable for its regulated control outcomes.
• Integration proves coverage: An interface can be late, partial, duplicated, transformed, or silently failed; reconciliation proves coverage.
• The vendor's audit report proves fitness: Supplier assurance is an input; the institution must test its local population, configuration, workflow, action, and resilience.
• A central platform eliminates local risk: Local law, data, language, products, reporting, and action authority require governed Local Edge decisions.
• A successful go-live proves remediation: The organization must show historic scope, interim controls, outcome testing, evidence replay, and recurrence monitoring.

Executive Architecture and Vendor Checklist

• Approve the control outcome, scope, legal-entity accountability, action boundary, residual risk, and senior owner before a material platform or supplier commitment.
• Require a dependency map that includes common cloud, identity, data, workflow, model, and implementation dependencies—not only direct vendors.
• Review data permissions, evidence export, audit/support rights, change control, concentration, resilience, and exit before contract approval or renewal.
• Fund data reconciliation, workflow capacity, action confirmation, monitoring, fallback, and remediation alongside feature delivery.
• Set risk tolerances for missing population, service degradation, action delay, evidence loss, and untested local configuration.
• Require proof that Global Core standards and Local Edge obligations are both executable and visible in management information.

Operator Control-Stack Checklist

• Maintain a control map linking scope, source systems, data contracts, signals, workflow, action channels, evidence stores, owners, and local overlays.
• Reconcile expected and received customer, transaction, list, and event populations at material ingestion and handoff points.
• Record rule, model, list, workflow, permission, and configuration versions with effective dates, approvals, test evidence, and rollback.
• Confirm material actions through the destination system and surface failed or pending acknowledgements to case owners.
• Operate documented degraded-mode, manual-workaround, recovery, and post-restoration reconciliation procedures.
• Route vendor incidents, data defects, access issues, release failures, and capacity breaches into accountable issue management.

Specialist Design and Assurance Checklist

• Define authoritative sources, link keys, permitted-use constraints, required fields, freshness, error handling, and reconciliation for every material interface.
• Test full end-to-end workflows including adverse data, late and duplicate records, unavailable enrichment, bad list update, queue overload, permission failure, and action rejection.
• Separate source fact, derived enrichment, candidate signal, reviewer conclusion, and confirmed action in schemas and user interfaces.
• Maintain evidence export, log retention, configuration archive, supplier support records, and reproducible decision replay for material controls.
• Assess common-mode supplier and technology concentration, subcontractors, cloud regions, identity dependencies, and key-person exposure.
• Test exit, replacement, parallel-run, and recovery capability before a critical relationship is in distress.