The Financial Stability Board has reclassified your AI agents as employees

On 10 June, the Financial Stability Board, the international body that coordinates financial regulation across the G20, issued a consultation report on sound practices for AI in finance. Most of it reads as expected. Twelve practices covering governance, lifecycle, data hygiene, cyber and third-party risk, with comments open until 22 July. The board members who signed off will be familiar to anyone who has tracked the Basel and FSB workstreams over the last five years. One sentence, sitting inside the section on autonomous systems, resets the legal category of agentic AI inside financial services. The FSB recommends that firms adapt their human resources controls to treat autonomous AI agents as synthetic employees.

It is a small shift in language. It is a very large shift in liability.

The conventional reading inside most banks treats agentic AI as a deeper version of the existing software supply chain. The agent calls APIs, the technical connection points other software uses to talk to the bank, and schedules tasks. On an architecture diagram, it looks like an unusually well-integrated workflow tool. So it gets the workflow-tool treatment. Model risk reviews the model. Enterprise architecture reviews the integration. Third-party risk reads the vendor's SOC 2 report. The vendor accepts an SLA and a slice of indemnity. The whole thing slots into the controls the bank already runs. There is real value in that continuity. The controls are mature, the audit functions know how to read them, and the supervisors are familiar with the rhythm of model risk committee reporting. The argument has logic on its side. It is the most efficient way to scale a new capability without breaking what already works. Proponents would add, fairly, that bolting on a parallel HR-shaped track for AI creates duplication and shadow oversight, and the right move is to deepen the model risk regime rather than invent a second one. The institutions that hold this view have been right before. The same logic carried them through cloud, robotic process automation, and the first generation of machine learning models. Each time, the existing controls absorbed the new technology and the bank kept moving without inventing a parallel oversight regime.

The harder consequence is for delivery. The dominant consulting model in regional banking is built on a partition between strategy and build. One firm designs the governance and hands over a policy document. Another firm or an offshore unit writes the code. A control framework sits between them and is meant to make them line up. Agentic systems collapse that partition, because the policy is the code. The authorisation thresholds, the escalation paths, the kill switches, the tool permissions, the boundary between a human approving each agent action and a human only supervising the flow more loosely, all of these live as configuration inside the agent. They cannot be designed in one document and built by a different team six months later. A policy document can say that any trade above five million dirhams requires explicit human sign-off. The agent does not read the policy document. The configuration does, and the configuration was written by someone two steps downstream of the policy author, working from a one-line acceptance criterion in a Jira ticket. The intent does not survive the handover from partner to senior associate to offshore developer. By the time the agent ships, the threshold has become a default, and the default is wrong.

The work in the next two quarters is narrower than the consulting market will suggest. Start with an inventory. Every agent currently deployed or in pilot, the systems it touches, the actions it can take, the threshold at which a human is in the loop and at which a human is on the loop, and the audit trail it produces. The inventory should include the agent's tool permissions, the systems it can read from, the systems it can write to, the maximum value of action it can take without escalation, and the response time of the escalation chain. Each entry should be testable. A name and a phone number is not an escalation path; a name with response-time obligations and a documented back-up is. The inventory will be uncomfortable. It will surface agents commissioned by business lines outside the model risk regime, and agents whose threshold logic exists only inside a prompt nobody owns. Then the HR-shaped policy. What each agent is permitted to do, who in the bank is the named accountable owner, what triggers escalation, what the off-switch is, and who in the building has the authority to use it. Only then does the engineering work begin. The named owner needs the authority to challenge the agent's design before it ships, and the technical literacy to understand what they are being shown. The named accountable owner has to attend the model risk committee. That is the practical test. If the role exists only inside an org chart and not inside the room where decisions are made, the agent has no human owner the supervisor can find. That pairing is rare inside banks, and rarer inside the firms that sell to them. Building it is the work of 2026.