If you deploy machine learning in financial services today, you are caught between two moving targets. On one side, the EU AI Act (2024/1689) classifies credit scoring, insurance pricing and several trading applications as high-risk AI, with conformity assessment obligations attached. On the other, the international standards that are supposed to tell you how to comply are still maturing — and, as I'll argue below, they leave a critical layer unspecified.
Over the past three months, as part of a StandICT.eu 2029 fellowship, I have been analysing the four ISO/IEC standards most relevant to trustworthy AI in finance, from the perspective of someone who builds these systems rather than someone who audits them. All of the analysis is public, MIT-licensed, and available in the project repository.
The four building blocks
ISO/IEC 42001 (AI management systems) gives you the governance backbone: accountability, roles, organisational controls. It is genuinely useful if you run a portfolio of AI systems rather than one model. What it does not give you is quantitative reliability thresholds, retraining governance, or anything sector-specific.
ISO/IEC 23894 (AI risk management) frames reliability failures, harm and control breakdowns as risk questions, bridging AI concerns with enterprise risk thinking. But its practical value depends almost entirely on local interpretation — it does not define financial-sector operating thresholds, evidence bundles, or escalation rules.
ISO/IEC 5338 (AI system life cycle processes) structures the engineering lifecycle from development through retirement. Its strongest contribution is process discipline at handoff points — which is where many trust failures in finance actually originate. Its weakest area is live adaptive systems: frequent retraining, vendor model updates, post-deployment revalidation.
ISO/IEC TS 25570 (reliability assessment of AI systems), still under development, is the most directly relevant of the four for live reliability. It elevates reliability into a distinct assurance concern instead of burying it inside generic governance language. But institutions will still need their own operating model for when to reassess and what evidence a continued-use decision requires.
The missing layer
Put the four together and a pattern emerges: governance, risk, lifecycle and reliability are each covered somewhere, but no standard tells a bank or fintech what to do when a live system changes underneath them. Concretely, current standards under-specify:
- Concept drift — how to connect drift detection to materiality thresholds, approval triggers and fallback actions, in markets that move faster than validation cycles.
- Retraining governance — which retraining events reopen approval conditions, and what evidence each tier requires.
- Third-party models — how a vendor's silent model update should re-enter your risk review.
- LLM and agentic systems — behaviour change through prompt, retrieval or orchestration changes, none of which look like a classical "new model version".
The implementation problem, in other words, is not choosing the right standard. It is integrating four partial viewpoints into one defensible operational control model.
A proposal: Continuous Reliability Assurance
My fellowship's central technical output is a proposal for Continuous Reliability Assurance (CRA): treating reliability as a continuously supervised control outcome rather than a one-time evaluation result. CRA is not a replacement standard — it is an integration layer that connects the four standards above to live-system supervision, built around three missing pieces:
- a trigger taxonomy for reassessment (drift, retraining, vendor update, incident, LLM behaviour change),
- a common evidence bundle for continued-use decisions after a live change,
- an escalation model linking reliability deterioration to governance action — restriction, rollback, or formal review.
The full proposal, along with a controls gap matrix rating all four standards against ten financial-AI control domains, is in the repository. If you work in model risk, AI governance or ML engineering in finance, I would value your criticism — issues and pull requests are open.
Why this matters for European SMEs
Harmonised, implementable standards are how compliance stops being a legal-interpretation exercise and becomes repeatable engineering. That shift disproportionately benefits smaller firms that cannot staff large compliance teams — provided practitioners are in the room when the standards are written. That is precisely the gap the StandICT.eu programme addresses: it funds European specialists, including SME founders and newcomers to standardisation, to participate in international standards bodies. If you build systems these standards will govern, I recommend applying to a future Open Call.
This work is supported by a StandICT.eu 2029 fellowship, "AI Standardisation for Trustworthy ML Systems in FinTech", funded by the European Commission. Views are the author's own and do not represent StandICT.eu, BSI, ISO, IEC or the European Commission.
Top comments (0)