Overview
Appendix E. Translating regulation into engineering requirements
This appendix explains how financial AI regulation becomes concrete engineering work. Rather than treating laws as abstract compliance issues, it maps the obligations to the systems, logs, documentation, validation processes, and controls that engineers must actually build. It also stresses that rules vary by jurisdiction and change over time, so teams should verify the current legal state before release and treat the appendix as an architecture guide rather than legal advice.
A major theme is model governance for credit, pricing, capital, and fraud systems. In the US and UK, supervisory frameworks require documented development, independent validation, inventory and version control, performance and drift monitoring, and challenger models. For lending and other consumer-credit decisions, the book emphasizes explainability, adverse-action notices, fair-lending testing, and the need to justify models that may have disparate impact even when they appear neutral. These requirements are reinforced by broader duties around consumer-report data accuracy and permissible use.
The appendix also covers the rapidly changing AI-specific rules and the surrounding operational controls. The EU AI Act imposes a high-risk regime for credit scoring with requirements for risk management, data governance, technical documentation, logging, transparency, human oversight, robustness, and registration, while US state laws and voluntary frameworks like NIST’s AI RMF push similar principles of documentation, testing, disclosure, and responsible governance. Beyond model regulation, the text ties AI systems to communications rules, data protection, AML, payments, resilience, and capital requirements, showing that deployed AI must satisfy customer-facing, privacy, security, and infrastructure obligations across the full financial stack.
E.6 The pre-production checklist
Before any model in this book reaches production, you should be able to point to:
- a model registry entry with lineage, version, validation report, and a named approver (SR 11-7 / SS1/23);
- reason codes or explanations mapping every decision to human-readable factors (ECOA, GDPR Article 22, EU AI Act Articles 13–14);
- a fairness test in the validation gate (fair lending, EU AI Act Article 10);
- immutable logs of inputs, outputs, and overrides (EU AI Act Article 12, DORA, FINRA recordkeeping);
- a human-in-the-loop path for consequential and customer-facing actions (GDPR Article 22, FINRA 2210, Chapter 14's Draft-Approve queue);
- drift and performance monitoring with escalation thresholds (SR 11-7 ongoing monitoring, Chapter 6);
- third-party dependency governance for any external model or API (DORA).
A closing caution on dates: between this book's writing and your reading, several of these regimes—especially the EU AI Act's high-risk timeline and US state and federal guidance—are likely to have moved again. Use this appendix for the mapping from obligation to engineering artifact, which is stable, and verify current effective dates before relying on any specific one.
FAQ
What is the main purpose of Appendix E in Financial AI in Practice?
Appendix E translates major regulations and supervisory rules into concrete engineering requirements, showing what systems must be designed, built, logged, monitored, and documented to operate compliantly in regulated financial environments.Why does the appendix warn that regulation must be checked by jurisdiction and date?
Because obligations differ across regions such as the US, EU, UK, and Korea, and because AI-related rules and enforcement positions change frequently. The appendix reflects the state of play in mid-2026, but teams should re-verify before shipping.What does model risk management require engineers to build for US and UK banking models?
For US banks, SR 11-7 and OCC guidance require documented development, independent validation with effective challenge, a versioned model inventory, ongoing drift and performance monitoring, and challenger models. The UK’s PRA SS1/23 requires similar governance, validation, and mitigants, and firms operating in both markets should build to the stricter regime.Why is explainability treated as mandatory for credit decisions?
Because US fair-lending rules require that declined applicants receive specific and accurate reasons for the decision. A black-box model is not a valid excuse, so systems must generate reason codes tied to the actual factors used by the model.What engineering controls are needed to satisfy ECOA and Regulation B adverse-action rules?
Systems need adverse-action notices that state specific, accurate reasons reflecting the model’s actual decision factors. In practice, this often means building explainability methods such as SHAP, LIME, or weight-of-evidence reason codes.How do FCRA obligations affect AI systems that use consumer-report data?
They add separate adverse-action duties along with data-accuracy and permissible-purpose requirements. Engineers must ensure consumer-report data is used lawfully and that downstream decisions can still be explained correctly.What does the EU AI Act require for high-risk credit scoring systems?
It requires a risk-management system, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy/robustness/security measures, and registration in the EU database. Creditworthiness assessment of natural persons is classified as high-risk.How should teams handle the changing effective dates of the EU AI Act for credit scoring?
They should treat the high-risk classification as settled but avoid hard-coding a fixed compliance date until the Omnibus changes are fully published and binding. The appendix notes that timing is moving and should be rechecked before implementation.What are the key data-protection requirements for AI systems under GDPR and CCPA/CPRA?
Teams must implement lawful basis, data minimization, retention limits, and PII scrubbing before data enters a RAG corpus or embedding store. For automated decisions under GDPR Article 22, they also need safeguards such as human intervention, the right to contest, and meaningful information about the logic involved.Why is DORA important for AI systems in EU financial firms?
DORA treats AI systems as ICT systems, so it imposes ICT risk management, incident reporting, resilience testing, third-party risk management, and information-sharing requirements. That means even an external LLM API becomes a governed dependency that must be controlled and monitored.
Financial AI in Practice ebook for free
