Further Reading
Chapter 40: Integrating the RegTech Stack — A Full Program Review
Essential Reading
Basel Committee on Banking Supervision. (2021). Principles for Operational Resilience. Bank for International Settlements. The twelve principles for operational resilience — including interconnectedness, data governance, and incident management — provide the international standard against which compliance program integration is assessed. Principle 6 specifically addresses information and communication technology as a source of operational risk; Principle 9 addresses third-party and outsourcing dependencies. Available freely at bis.org.
European Banking Authority. (2022). EBA Report on the Use of RegTech in the EU Financial Sector. EBA. The most comprehensive regulatory survey of RegTech deployment in European financial services. Includes findings on integration challenges, data architecture gaps, and the gap between individual system capability and program-level coherence. Directly supports the chapter's central thesis that tool deployment does not automatically produce program capability. Available at eba.europa.eu.
Federal Reserve / OCC / FDIC. (2011). SR 11-7: Guidance on Model Risk Management. Federal Reserve Board of Governors. The foundational document for model risk management in the US financial services sector. Establishes the three-pillar model governance framework (development and implementation, validation, governance) and the requirement for ongoing monitoring — not just initial deployment validation. Directly applicable to every analytical model in the compliance technology stack.
For Practitioners
Buehler, K., Freeman, A., & Hulme, R. (2008). The Risk Revolution. McKinsey & Company. While predating the current RegTech era, McKinsey's analysis of enterprise risk management integration provides the strategic framework for thinking about compliance technology as a cross-enterprise capability rather than a domain-by-domain investment. The integration challenge for compliance technology is a specific instance of the broader enterprise risk data architecture challenge this work describes.
Collier, P. (2015). Fundamentals of Risk Management for Accountants and Business Professionals. CIMA / Elsevier. A practitioner-oriented framework for integrated risk governance that is directly applicable to compliance technology program design. The discussion of risk information aggregation — how to combine risk data from across an organization into coherent management information — mirrors the compliance program integration challenge.
Financial Stability Board. (2023). FSB Report on Artificial Intelligence and Machine Learning in Financial Services. FSB. The FSB's survey of AI/ML deployment in financial services includes extensive coverage of data architecture, model governance, and the integration challenges that arise when AI systems interact with legacy infrastructure. Particularly relevant for compliance programs that are layering AI capabilities onto existing technology stacks.
Technical Architecture
Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems. 2nd ed. O'Reilly Media. The standard reference for microservice architecture — the design pattern most commonly used for compliance technology integration. Newman's treatment of service boundaries, data ownership, and inter-service communication maps directly to the compliance technology integration challenge: how do you enable data sharing between systems while maintaining clear ownership boundaries?
Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media. The most rigorous technical treatment of distributed data systems — the infrastructure category that underlies the compliance data lake, the unified customer master record, and the audit log aggregator. Kleppmann's treatment of data consistency, immutable event logs, and stream processing is directly applicable to the integration architecture described in this chapter.
Fowler, M. (2018). Patterns of Enterprise Application Integration. Addison-Wesley. The foundational catalog of enterprise integration patterns — event-driven messaging, API gateways, shared databases, canonical data models. The chapter's integration architecture draws on several of these patterns, and Fowler's treatment provides the conceptual vocabulary for discussing them precisely.
Regulatory Primary Sources
| Document | Jurisdiction | Relevance to Integration |
|---|---|---|
| PRA SS1/21 (Operational Resilience) | UK | Requires firms to map important business services and the people, processes, technology, and data that underpin them — the operational resilience mapping exercise requires the same data flow understanding as the integration program |
| DORA Chapter II (ICT Risk Management) | EU | Requires firms to maintain an ICT asset register and to understand the dependencies between ICT assets and business functions — directly supports the integration program |
| DORA Article 30 (ICT Third-Party Risk) | EU | Requires contractual provisions ensuring data portability and integration capability from ICT third-party providers |
| EBA GL/2021/05 (Internal Governance) | EU | Chapter 8 covers information systems management including data quality, data governance, and management information requirements — the governance dimension of integration |
| BCBS 239 (Risk Data Aggregation) | International | The core international standard for risk data aggregation and risk reporting — the compliance program integration architecture is an application of BCBS 239 principles to the compliance domain |
| SR 11-7 (Model Risk Management) | US | Establishes the ongoing validation requirement for all analytical models — the model governance component of the compliance program integration |
| FCA FG21/1 (Operational Resilience) | UK | Final guidance on operational resilience implementation, including data mapping requirements that intersect with compliance technology integration |
| ICO Data Protection by Design Guidance | UK | The UK GDPR requirement to consider data protection in system design is directly relevant to the integration architecture, particularly the customer master record and audit log |
Online Resources
Bank for International Settlements — Financial Stability Institute (bis.org/fsi): Publishes working papers and staff notes on regulatory technology, SupTech, and compliance automation. The FSI Insights series includes practical analysis of integration challenges in financial services compliance programs.
European Banking Authority — RegTech and SupTech (eba.europa.eu/regulation-and-policy/innovation-and-fintech): The EBA's RegTech hub includes reports, surveys, and consultation papers on compliance technology deployment. Their multi-annual report on RegTech in the EU provides the most authoritative landscape analysis available.
Basel Committee — Supervisory Technology (bis.org/bcbs): BCBS papers on data reporting, risk data aggregation, and supervisory expectations for compliance technology governance.
ISACA — IT Governance (isaca.org): The professional body for IT governance, risk, and assurance. Its frameworks (COBIT, CRISC) are the standard references for technology governance in regulated environments — applicable to the governance dimension of compliance technology program management.
Martin Fowler's website — Enterprise Integration Patterns (martinfowler.com): Free online version of the integration pattern catalog, with regular updates on modern integration approaches including event-driven architecture and microservices.
Suggested Reading Sequence
For the compliance professional new to integration architecture: 1. Start with the EBA RegTech Report (regulator perspective on the integration challenge) 2. Read BCBS 239 (the data aggregation standard that establishes the governance requirements) 3. Read SR 11-7 (the model governance framework) 4. For technical depth: Kleppmann's Chapter 11 on streaming data, then Newman's Chapter 4 on service decomposition
For the technology professional new to compliance context: 1. Start with SR 11-7 (establishes why model governance matters in this domain) 2. Read PRA SS1/21 and DORA Chapter II (the regulatory requirements that drive integration) 3. Read the FSB AI/ML report (regulatory perspective on technology risks) 4. For technical depth: Newman Part III (service integration patterns in microservice architectures)