Financial institutions
Your institution evolved. Did your risk framework?
New rails, new vendors, new models, new exposure. AI is already in the decision path. Risk has moved. Yet many frameworks still report the institution as it used to be. A register records known risks. It cannot reveal what the framework was never designed to see.
What keeps opening the gap
Financial institutions are modernising faster than at almost any point in their history. Instant payments, account-to-account transfers, digital onboarding, scoring engines and fraud tools have arrived in a few short years — often against regulatory deadlines that left no room to design controls alongside the systems.
At the same time, disruption has stopped being exceptional. Cyber incidents, vendor outages, sanctions shifts, infrastructure failures and geopolitical events now interrupt operations often enough that continuity is an operating condition rather than a contingency. The question is no longer whether something will fail, but which services cannot be allowed to stop and for how long.
AI has compounded both. It sits inside vendor products as often as in systems the institution built, it makes or shapes decisions nobody in risk was asked to approve, and it introduces failure modes — drift, opacity, dependency on a provider’s model — that existing frameworks were not designed to catch.
Meanwhile the risk function is expected to keep pace with methodology it inherited, accountability for systems it was never consulted on, and reporting cycles built for a slower institution. Capable teams, working with instruments designed for a different problem.
Small, ordinary, and expensive
Risk consulted after the decision
The business case is approved, the vendor is selected, the timeline is fixed. Then risk is asked to review it. By that point the only available answer is how to mitigate a decision already made.
Controls that did not survive the migration
The old process had a reconciliation, a second signature, a daily check. The new system was tested for function, not for control. Nobody mapped what was there before against what exists now, and the gap only surfaces when something goes wrong.
Vendors assessed for what they used to do
The due diligence was done at onboarding, when the vendor did one thing. Its role has expanded since — more data, more processes, more dependency — and the assessment has not been repeated. Concentration builds quietly.
Incidents that never became findings
Something went wrong, was fixed, and was closed. It was not logged as a loss event, no root cause was recorded, and the same weakness is still there. The institution has learned nothing it could not already see.
A register documents what you already know. It does not see what is coming.
What we do
Each engagement is scoped to a defined outcome — a question worth answering. Most begin as an assessment. What comes after depends on what it finds.
Risk in change and transformation
Migrations, new payment infrastructure, offshoring and process redesign are where control gaps are born. Before a change, an assessment of what could go wrong and what needs protecting. During it, a map of which controls must survive the transition. Afterwards, a review of which ones actually did.
The window matters — six months on, the people who knew what changed have moved, and the review becomes archaeology.
Operational risk frameworks
Most institutions have a framework. Fewer have one people use and get value from. The work is assessment of what exists against Basel principles, regulatory expectations and international standards, design of what is missing, and — the part that usually decides whether any of it matters — getting it into how the business actually runs.
Built for the institution rather than adapted from a template. Tailored to its structure. Customised to its needs. Done properly, the framework stops being a reporting obligation and becomes what management uses to make risk-based, informed decisions.
Operational resilience
Most institutions have a continuity plan. Far fewer can say which services cannot be allowed to stop, for how long, and what happens to customers when they do. That is the question supervisors have started asking, and it is a different question from the one a BCP was written to answer.
Plans usually exist. They fail on the day for ordinary reasons — never tested, not updated after the last change, written for how the institution used to work, or missing a dependency nobody thought to include. The work is finding those gaps before an incident does.
Identifying the services that cannot stop, mapping what they depend on, setting tolerances for disruption, and building recovery arrangements that hold when something actually fails. Delivered against a structured framework rather than from a blank page.
AI and technology governance
Banks have managed model risk for years. AI is not the same problem. The model is increasingly not yours — it arrives inside a vendor product, it changes after deployment, and it is asked to explain itself to people who cannot see inside it. Meanwhile the systems have started to act rather than score.
The work is establishing where AI enters the institution, what it decides, how those decisions are classified and monitored, and who is accountable when one of them is wrong. Model inventory, risk classification, vendor and embedded-AI assessment, and the governance a supervisor will eventually ask to see.
This is governance and accountability work, not statistical validation. The questions supervisors ask are rarely mathematical — they are about authority, consent and liability, which is where risk practice meets contract and regulation.
Assurance and control testing
Most testing confirms that a control exists. Less of it confirms that the control works — that it was performed, by someone who understood why, in a way that would have caught the thing it was designed to catch.
Controls often fail between functions, where processes change hands but accountability does not. The work assesses control design and operating effectiveness end to end, identifying ownership gaps, duplication, and controls that no longer match the scale or speed of the risk. Controls are calibrated so their cost and effort remain proportionate to the risk reduction achieved, while testing focuses on key controls and areas of greatest residual risk.
Preparation for supervisory examination or internal audit, and independent review where an internal assessment is not enough — because the conclusion needs to come from outside the function that produced it.
AML and sanctions control effectiveness included. For institutions with correspondent relationships, that is rarely a compliance question alone.
Training
Working sessions rather than slide decks, built for the audience in the room. Risk teams leave with methodology they can run themselves. Boards and senior management leave knowing which questions to put to their own people — particularly on technology and AI, where most are not yet asking the right ones. Staff sessions focus on what to notice and when to escalate, which is where most incidents are either caught or missed.
Frameworks do not fail because they are badly designed. They fail because nobody understood why they existed. Culture, knowledge and awareness are what turn a framework from a document into something the institution actually operates — and they are usually the part nobody budgeted for.
Where these claims come from
Financial services is not an adjacent sector for this practice. It is where most of the twenty years were spent.
Standard Chartered
Head of Governance and Control across all operational units, Head of Consumer Banking Operations with around thirty direct reports, and Head of Risk for Technology and Operations. The operational risk framework covered trade services, cash management, cards, lending and corporate credit — in an institution that was simultaneously consolidating back office into an offshore hub, replacing systems and redesigning processes. Assessing risk in change was not a separate assignment. It was the condition the framework had to work in.
Jordan Ahli Bank
Operational risk across the branch network, overseas branches in Cyprus and the Palestinian Territories, and microfinance, leasing and brokerage subsidiaries. Four business models with four risk profiles, under one group framework that had to work for each without pretending they were alike. RCSA oversight, loss event analysis, Board Risk Committee reporting, and regulatory support across ICAAP, stress testing and recovery planning.
Egyptian Arab Land Bank
Established operational risk and information security from inception — framework, RCSA methodology, KPI and KRI design, loss event process and management reporting, implemented across every business unit. Nothing inherited, nothing to adapt from.
Independent practice
Consulting and training across several industries, including hands-on work with a microfinance business — branch processes, cash handling, loan officer controls. The level at which a framework either holds or does not.
Qualifications
LLM in International Commercial Law and Technology and an LLB, which is why the advice reaches where liability sits rather than stopping at the control gap. MBA in Finance. Certified ISO 31000 Senior Lead Risk Manager.
Services for humanitarian organisations.
Humanitarian sectorStart with a conversation
Most first conversations start with one of these. Risk arriving after the decision was made. A control environment nobody has tested. A resilience question you have not been asked yet but will be. A model nobody can explain. An examination coming. Starting that conversation carries no obligation.