A quiet month for anyone waiting on a new rulebook
October 2026 did not produce a single global AI law. It produced something more useful for a board. Supervisors described, in plain language, the difference between an AI program that can be explained and one that cannot.
On 19 October the UK Financial Conduct Authority published AI in financial services: good practice and areas for improvement. It does not create new rules. It says the examples are illustrative, and that firms remain responsible for deciding what is proportionate. The same month, the Monetary Authority of Singapore issued guidelines on AI risk management, and the Hong Kong Monetary Authority updated its supervisory guidance and put out a concept note on agentic AI.
Read together, they ask the same question the operator already has. Who owns this system, what is it allowed to do, and what evidence exists of what it did.
The failure they describe is the handoff
The FCA's poor-practice examples include firms that designed and deployed a use case before deciding how to govern it, then tried to fit it into an existing framework after the important design choices were made. Retrofitting left gaps. When something went wrong, more than one team believed oversight sat somewhere else.
That is the roadmap problem in a supervisor's words. The decision and the system had different owners. Accountability cannot be added at the end of that sequence.
Jessica Rusu, the FCA's chief data, information and intelligence officer, put the same point in a speech the day the examples were published. Firms need clear accountability, risk-based controls, human oversight, escalation triggers, and senior managers who are personally accountable. She described governance added after deployment as the wrong way around.
What "good" actually requires
The publication is not a maturity model. The practices it treats as sound are operational:
A senior manager who is accountable
Not a committee that reviews a slide. Someone who can take reasonable steps to mitigate the risk of that system, including systems the firm bought rather than built.
Escalation that is designed
The firm decides in advance which tasks the system may support, which stay with a person, and where it must stop and hand over. A person in the loop who cannot challenge the output is not oversight.
Monitoring of outcomes, continuously
The FCA contrasts dashboards, thresholds, and audit trails with reviews that happen long after the fact, and with monitoring that watches technical metrics while missing what happened to the customer.
Governance before autonomy
For more autonomous, agentic workflows, the examples of good practice are firms that designed escalation, compliance controls, and human oversight before deployment. Not after the agent could already act.
Singapore's guidelines, published on 7 October and taking effect on 7 October 2027, point the same direction: board and senior-management oversight, an inventory of AI use, controls across the life cycle, and accountability for AI that a third party operates. Hong Kong's 15 October guidance expects an owner for each deployed use case, and opens the question of how human oversight changes when a system can act.
The poor practice, as a board question
| What supervisors are marking down | What to ask on Monday |
|---|---|
| Governance fitted on after the design | Who was accountable when the design was chosen? |
| Oversight that several teams assume sits elsewhere | Who can stop this system, and how fast? |
| Technical metrics, reviewed from time to time | Can we show what it did to a customer last week? |
| An agentic workflow with no governance layer first | What is it allowed to do, and where must it escalate? |
| A model the firm depends on and has not planned to lose | What happens if that supplier, or that model, fails? |
This is not a reason to build a second compliance function
The FCA is explicit that there is no single model, and that smaller firms should not copy a large-firm apparatus. MAS says existing governance structures can be enough where they actually oversee the risk. The demand is not a new department. It is evidence that the structure you already have can see the system, challenge it, and name an owner.
A policy that describes those intentions, written after the pilot, will not meet that test. The record has to show the decision, the limit, the escalation, and the outcome.
What I would take into the room
If a risk committee has one discussion off the back of this month, I would make it this. Pick the AI system that already touches a customer or a control. Ask who owns it, what it is allowed to do, what evidence you have of last week's behavior, and what you will do if the model you depend on changes or fails. If those answers are split across a strategy deck, a vendor, and an operations team, the program is in the poor-practice column already.
This is not legal advice, and it is not a summary you should hand to a supervisor in place of the publications themselves. Views here are my own.
Related: Agent Observability: What Boards Actually Need · Why the AI Roadmap Never Reaches Production