Every function owns a component. Nobody owns the system. That is a design problem, and it now has a name. Financial Intelligence Architect.
By Mark Chen, Program Director, International Council for Derivative Trading
Ask a financial institution’s executive committee who is responsible for the firm’s use of artificial intelligence, and you will usually get five confident answers. Technology owns the platform. The chief data officer owns the pipelines. Model risk owns validation. Compliance owns the regulatory mapping. The business owns the outcome. Each answer is correct within its own frame, and the sum of them is a gap.
That gap was tolerable when AI in financial services meant a credit scorecard refreshed once a year and a churn model nobody outside marketing had heard of. It is becoming intolerable now. AI is used to review transactions, prepare research, support credit decisions, reconcile accounts, monitor conduct, detect fraud and interact directly with customers. In the 2024 joint survey by the Bank of England and the Financial Conduct Authority, 75% of responding firms said they were already using AI, with a further 10% planning to adopt within three years.
As adoption accelerates, the governance question changes shape. Institutions no longer need only to decide whether a model is accurate enough to deploy. They must determine who is accountable when a system draws on internal data, depends on a third-party model, interacts with employees or customers, calls other tools, changes over time, and produces an outcome with financial, regulatory or reputational consequences.
Most institutions already employ the necessary specialists. They have technology leaders, data scientists, model validators, risk officers, compliance teams, cybersecurity functions, procurement, business owners and internal audit. The weakness sits between them. Each team owns a component. No single professional owns the integrity of the whole design.
That is the gap the Financial Intelligence Architect is designed to fill.
The Gaps a Financial Intelligence Architect Can Fill
A typical AI-enabled financial process crosses several organizational boundaries. Consider an AI agent assisting with credit underwriting. The business unit defines the commercial objective. A vendor may provide the underlying model. Data teams connect internal and external information. Technology integrates the system into existing infrastructure. Compliance interprets consumer protection and disclosure requirements. Model risk tests performance and limitations. Cybersecurity assesses access and attack surfaces. Operations determines when a human must intervene.
Every one of those functions can perform its assigned task correctly and the institution can still end up with a poorly governed system.
The failures that follow are rarely dramatic, and almost none of them belong to a single desk. A retrieval system quietly indexes a document repository that stopped being maintained eighteen months ago. That is not a modelling failure, an infrastructure failure or a compliance failure, and it will pass through four functional reviews without anyone owning the question. A vendor updates its underlying model and the behavior of the deployed system shifts with no internal change record, because procurement treated the arrangement as a software license. A human sits nominally in the loop but reviews at a volume and speed that makes meaningful review impossible, so the control exists on the policy map and nowhere else. A system approved for internal summarization gradually finds its way into client-facing material, and the approval that governs it describes a use case that no longer exists.
Governance by committee becomes accountability by diffusion. When a system fails, the institution discovers that several people were responsible for a component and nobody was responsible for ensuring the components formed a coherent and controlled whole.
What supervisors specify, and what they leave out
Regulators have reached the same conclusion from the outside, and their response has been to mandate oversight without describing who the overseer should be.
The EU AI Act requires that high-risk systems be subject to human oversight by people with the competence, training and authority to exercise it, and reinforces this with obligations covering risk management, data governance, logging, documentation, accuracy, robustness and cybersecurity. It does not define that competence. In the United Kingdom, supervisory expectations on model risk management extend governance to a far wider population of systems than most firms had previously inventoried, and place accountability on named individuals under the Senior Managers Regime. They specify the obligation, not the qualification. Operational resilience and third-party rules apply squarely to AI vendor dependency without addressing who inside the firm is equipped to assess it.
The supervisory direction has become explicit about the lifecycle. IOSCO’s Supervisory Toolkit for AI Use in Capital Markets, published in May 2026 and covered by this publication at the time, spans the full life of an AI system and applies across system types, from traditional machine learning to generative and emerging agentic techniques. It addresses governance and risk management, third-party dependency, disclosure, recordkeeping and reporting. NIST’s AI Risk Management Framework organizes the same challenge into four linked functions: govern, map, measure and manage. The instruments differ in legal status and jurisdiction. They point at the same operational reality. Institutions must be able to explain not only what a model does, but how the entire system is selected, designed, deployed, monitored, changed and retired.
The common structure across all of them is worth noting. A named human must be capable of overseeing the system, and no framework anywhere states what that human needs to know. Supervisors have created a role requirement and left the labor market to fill it. The labor market has answered with the credentials it already had, which were written for market risk, credit risk, accounting and compliance, and which say nothing about retrieval architecture, evaluation design, drift detection or vendor change control.
The problem has been characterized formally. In a working paper published through ICFDT, Michael Clark applies principal-agent theory to AI delegation and describes the result as a governance accountability gap: a structural mismatch between the AI capabilities firms deploy and the oversight competencies available to govern them. His central claim is that regulatory mandate alone cannot close it, because accountability requires competency. The human overseers that regulators require must hold verifiable, domain-specific knowledge that existing professional credentials do not supply. That framing is useful because it locates the problem in the labor market and the org chart rather than in the technology, which is where most institutional responses have been aimed.
Why traditional structures struggle
Financial institutions have long experience governing models, technology, outsourcing, data, conduct and operational risk. AI combines all of them in ways that do not fit neatly inside any single existing discipline.
Traditional model risk processes were designed around relatively bounded systems with defined inputs, outputs, owners and validation cycles. Modern AI applications combine foundation models, retrieval systems, prompts, external tools, human feedback, vendor updates and multiple agents dividing a task among themselves. The model is one component of the resulting behavior, and often not the component that fails.
This produces a set of recurring governance failures that appear across institutions of very different sizes and sophistication.
Five recurring failure points
1. Incomplete inventories. AI enters through approved projects, embedded vendor features, employee tools, spreadsheets and small workflow automations. Institutions cannot govern systems they have not identified, and the inventory is almost always shorter than reality.
2. Weak use-case classification. The same underlying model presents very different risks when used to summarize an internal document, recommend a trade, communicate with a customer or influence access to credit. Governance must begin with purpose, context and consequence rather than the vendor’s product description.
3. Controls detached from architecture. Policies require human review, traceability, data protection or output testing without specifying where those controls operate technically, who receives an alert, and what happens when a threshold is breached. A control that cannot be located in the system is a statement of intent.
4. Third-party opacity. Institutions depend on models and infrastructure they did not build and cannot fully inspect. Contractual protections, testing rights, update notification, fallback arrangements and concentration risk all become part of AI governance, and procurement processes designed for software licensing handle none of them well.
5. Unclear authority during incidents. A system can behave unexpectedly without producing a conventional technology outage. Institutions need predefined authority to restrict functionality, revert to a previous version, require manual processing, notify affected parties and preserve evidence. Deciding this during the incident is too late.
The Financial Intelligence Architect
The Financial Intelligence Architect is the professional responsible for translating business objectives into a governed AI architecture, and for maintaining the connection between system design, financial purpose, risk controls and regulatory obligation.
The role is broader than a technical architect and more operational than a policy specialist. It does not replace the chief risk officer, compliance, model validation, cybersecurity, the business sponsor or internal audit. It creates the integrated design and evidence base that allow those functions to discharge their own responsibilities.
A Financial Intelligence Architect should be able to answer six questions for every material AI system.
Six questions every material AI system must answer
What is the system intended to do? The answer must define the users, decisions, data, actions and limits of the use case, not merely describe the model.
How is the system constructed? This covers the model, prompts, data flows, retrieval sources, tools, vendors, interfaces, human checkpoints and downstream dependencies.
Which risks and obligations apply? The system must be classified by financial impact, customer impact, regulatory requirement, autonomy, explainability, data sensitivity and operational criticality.
Where are the controls implemented? Each requirement maps to a technical, procedural or organizational control with a named owner and a test method.
How will the institution know when performance changes? Monitoring must address data quality, output quality, drift, bias, misuse, security, vendor changes, human overrides and business outcomes.
Who has authority to intervene? Escalation, restriction, shutdown, fallback, incident reporting and remediation must be decided before deployment.
These six questions convert AI governance from a set of broad principles into an operating architecture. An institution that can answer them for every material system has governance. An institution that can answer them only for the systems that reached the model risk committee has a policy.
A role with authority, not another committee
The obvious objection is that this adds a layer to institutions that already have too many. The answer is that the layer already exists. It is distributed across four or five functions in fragments, each carrying a partial view and none carrying the whole. Consolidating fragmentary accountability into a defined role is not additive headcount over any meaningful horizon.
Placement matters more than title. Positioned inside technology, the role loses independence from delivery pressure. Positioned inside compliance, it loses the technical standing to challenge an engineering decision and becomes a documentation function. The default that works is second line, with a direct reporting line to whoever holds senior management accountability for AI, the standing to withhold approval at defined lifecycle gates, and the technical credibility to make that withholding stick.
Boards and executives remain responsible for risk appetite and strategic direction. Business sponsors remain accountable for the outcomes of the processes they operate. Compliance, model risk, cybersecurity, legal and data governance provide specialist challenges. Internal audit provides independent assurance. Within that structure, the Financial Intelligence Architect owns the integrated blueprint: a common system inventory, an architecture record, a control map, monitoring requirements, change-control triggers and a defined escalation path.
Scale determines shape, not principle. A smaller institution may have one senior professional performing the role across a limited portfolio. A global bank may need a central architecture office with domain specialists embedded in business lines. The mandate must be explicit in either case. Coordination without authority produces documentation rather than control.
Governed speed is the competitive advantage
Institutions often frame AI governance as a trade-off between control and innovation. In practice, weak governance is what slows deployment. Projects sit in review cycles because requirements surface late, evidence is inconsistent across functions, and no one can produce a single account of what the system does. Every reviewer asks for a different artifact, and each request restarts the clock.
Firms with a defined architecture function move faster for an unglamorous reason. The questions are asked at design time, when answering them is cheap, rather than at approval, when answering them means rebuilding. Use-case classification at the start of a project is the least expensive control available and the one most frequently skipped.
The gap between governed and ungoverned deployment widens as systems become more autonomous. An agent that retrieves information, makes recommendations, drafts communications, updates records or initiates transactions has a far larger operational footprint than a model producing a score for human review. Its governance cannot be reduced to a one-time validation event. It requires continuous architectural accountability, exercised by someone whose job that is.
Building the profession
The people best positioned to become Financial Intelligence Architects come from technology, risk, finance, audit, compliance, data and model governance. Each background supplies part of the foundation. The role demands the additional ability to connect those disciplines and to make trade-offs visible to technical teams and senior decision-makers at the same time.
The Chartered Financial Intelligence Architect designation was created by the International Council for Derivative Trading to define and assess this interdisciplinary body of knowledge for financial services. Its scope covers AI architecture, data and model governance, implementation oversight, risk, regulation, controls, and the translation of AI capability into financial use cases. The purpose of setting it out as a formal standard is verifiability. A board asking whether its AI oversight function is competently staffed, and a supervisor asking the same question from outside, both need an answer that does not rest on assertion.
The wider point is a familiar one in this industry. Derivatives markets grew faster than the professional infrastructure to govern them, and the gap closed when specialist expertise became a defined discipline with a defined body of knowledge. Structured credit repeated the pattern. AI in financial services is at the same stage, with institutional adoption running well ahead of the professional standard required to supervise it.
The institutions that lead in AI will not be those deploying the greatest number of models. They will be those that can identify valuable use cases, build controls into the architecture, monitor the resulting systems, and assign clear accountability from design through retirement. They will be the ones that can answer the simplest supervisory question, which is not whether the model is accurate. It is who, by name, is accountable for this system, and what do they actually know.
Someone must own that integrated responsibility. That is the work of the Financial Intelligence Architect.
About the author
Mark Chen is Program Director at the International Council for Derivative Trading (ICFDT). ICFDT administers the Chartered Financial Intelligence Architect (CFIA) designation, which focuses on AI architecture, implementation, governance and oversight in financial services.
