Skip to main content
    SectorsBanking and capital markets

    Two supervisors, one estate, and they disagree about AI.

    In a bank a change to a production system is something a validator, an internal auditor or a supervisor may ask about years later, long after the person who made it has moved on. Reign operates the software delivery estate and records how each change was proposed, reviewed and approved, and by whom. Whether that record satisfies your obligations is a determination for your own risk function.

    Two available today, one in beta Start a conversation Regulatory alignment →

    We sit in the first line. We do not perform validation, independent review or effective challenge on our own work, and nothing we deliver is designed to stand in for your second or third line.

    One estate, two regimes both apply
    OSFI E-23, Canada SR 26-2, United States In the definition Statistical and quantitative AI and ML methods Generative and agentic effective 1 May 2027 In scope Statistical and quantitative Non-generative AI Outside the scope generative and agentic A firm operating in both is inside both. The gap is handed back to your own governance, not removed.
    Canada writes AI into the definition of a model. The United States writes generative and agentic AI out of scope. The estate does not change to suit either.
    The pressure

    The constraint is rarely writing the code. It is proving later that it was controlled.

    Everything on this page follows from one fact: the person who has to answer for a change is usually not the person who made it, and often not there any more.

    01Evidence outlives people
    The record of who authorized a change has to survive the team, the supplier and the platform.

    Teams move, suppliers are replaced, platforms are retired. What is left has to be readable by somebody outside the team, without a briefing.

    AskIf the engineer who made last year’s change has left, can you still answer for it?

    02Resilience is examined, not asserted
    Operational resilience is tested and reported on, including for the providers a firm depends upon.

    Under DORA that stopped being abstract in November 2025, when the European Supervisory Authorities designated the first critical ICT third-party providers. Statements of intent are not the artifact being asked for.

    AskCould you describe the failure modes of your delivery toolchain to somebody who intends to test them?

    03The two supervisors have moved apart on AI
    Canada writes AI and machine learning into the definition of a model. The United States places generative and agentic AI outside the scope of its revised guidance.

    That is not a detail. It means the fastest-growing part of the estate is inside one regime and outside the other, and a firm operating in both is inside both. The section below sets out what each actually says.

    AskWhich of your AI-assisted processes would your own model inventory currently capture?

    04Out of scope is not ungoverned
    Where guidance stops, it hands the question back to you rather than removing it.

    SR 26-2 says so explicitly: a banking organization’s own risk management and governance practices should determine the controls for anything the guidance does not cover. The obligation moves; it does not disappear.

    AskWhose name is against the governance of the tools that fall outside your model inventory?

    What the frameworks ask

    Three regimes, named with their dates and their current status.

    We describe what these ask for because they shape the work. We claim nothing about our standing under any of them, and the status column is there because two of the three changed in the last twelve months.

    What is measuredWhose figure, and whenWhy it is on this page
    OSFI Guideline E-23, Model Risk Management (2027) — governance across the whole model lifecycle, from development through implementation and use to decommissioning, proportionate to the risk a model carries. Its definition of a model reads “including AI/ML methods”.Canada. Final 11 September 2025, effective 1 May 2027.Scope widened from deposit-taking institutions to all federally regulated financial institutions, insurers included. AI is inside the definition rather than beside it, and the effective date sits inside the current planning cycle.
    DORA, Regulation (EU) 2022/2554 — ICT risk management, incident reporting, resilience testing, and the oversight of third-party providers a firm relies upon.European Union. Applying since 17 January 2025. First 19 critical ICT third-party providers designated 18 November 2025.The designated list includes the hyperscalers and integrators most delivery estates already run on. Third-party oversight stopped being a policy question and became a named list with a Lead Overseer attached to each entry.
    SR 26-2 and OCC Bulletin 2026-13 — revised interagency guidance on model risk management, covering development, implementation and use, supported by validation and effective challenge.United States. Issued 17 April 2026 by the Federal Reserve, OCC and FDIC. Supersedes SR 11-7 and SR 21-8.Most relevant to organizations above $30bn in total assets. Deliberately non-prescriptive about validation frequency, and footnote 3 places generative and agentic AI outside its scope while keeping non-generative AI inside it.

    Every date and designation above is the issuing body’s. Where we read a source rather than quote it, the page says which. Naming a framework is not a claim of standing under it, and iTmethods holds no certification, authorization or accreditation under any of the three.

    Where the record fits

    First line, and only the first line. That is what makes the rest work.

    The three lines of defence model works only when the lines are actually separate. We build, we operate and we record how the work was done, in the order it happened. We do not validate our own output and we cannot supply independence from ourselves — independence is the thing that gives effective challenge its value.

    What the record carries
    For each change: what was proposed, what the checks reported, who reviewed it, who approved it and when. Where a model took part, the identity that made the call, the policy that applied and the model that answered, joined to the change it produced. A named engineer is embedded for an agreed population, is accountable for the work in front of them, and appears in the record. They do not review their own approvals.
    The part worth being precise about. This is a record of how work was done, prepared so your second line can review it and your third line can audit it. It is not validation, it is not effective challenge, and it is not an opinion on whether your internal standard was met. iTmethods makes no compliance, certification or accreditation claim under any framework. How the boundary works → · Regulatory alignment →
    The four motions

    Where this sits against the rest of Reign.

    Four motions at four different stages of maturity. We state the stage every time, because in this sector the stage is the answer.

    Operate Reign Ops The delivery toolchain run as a managed estate, with change control, access control and a recorded history of who did what. Available today Build Reign Factory The motion that produces the work itself, under review, with a named approver on every merge. In beta and being productized; beta access is agreed and scoped in writing. Available · Beta Release Govern Reign Gateway Where model access, policy and logging sit, so the use of a model in the delivery process is a governed event with a record rather than an unobserved one. Available today Assure Reign Assurance Organises the evidence a reviewer needs into a form they can work through. It does not certify, does not attest, does not issue an audit opinion and does not provide independent assurance, in any tense. Co-design development

    A single-tenant dedicated instance, in your own AWS or Azure account or in infrastructure iTmethods operates. Both are available today, which includes deployment into your own cloud account; Google Cloud is planned for 2027. Air-gapped and sovereign are in development. There is no multi-tenant or shared option at any tier. Deployment options →

    Shared responsibility

    Who holds what, across the three lines.

    Written down before anything runs, because in a bank the boundary is itself an artifact somebody will ask to see.

    WhoWhat they hold
    iTmethods, first lineOperate the delivery estate inside your authorization boundary. Record how each change was proposed, reviewed and approved. Provide a named engineer for the agreed population who appears in the record and does not review their own approvals.
    Your second lineModel risk, compliance and operational risk. Review, challenge and the determination of whether a control is adequate. Whether your delivery tooling belongs in your model inventory is your determination, not ours.
    Your third lineInternal audit. Independent assurance over the whole of it, including over us. Nothing we deliver is designed to stand in for that, and we would treat it as a problem if it were used that way.
    Before the scoping call

    The questions that arrive every time.

    Does SR 26-2 mean AI is unregulated?
    No, and the page would be wrong to imply it. Footnote 3 places generative and agentic AI outside the scope of that guidance while keeping traditional statistical models and non-generative, non-agentic AI models inside it. It then directs a banking organization to its own risk management and governance practices for anything not covered. The obligation moves to you; it does not lift. The agencies have also signalled a separate request for information on bank AI use.
    Is our delivery toolchain a model?
    That is your determination and we will not make it for you. What we can say is that OSFI E-23 writes AI/ML into the definition and takes effect on 1 May 2027, that SR 26-2 excludes simple arithmetic and deterministic rule-based processes, and that the two answers may differ for the same estate. We would rather help you document the reasoning than assert a conclusion.
    Do you validate the work you produce?
    No. We are in the first line and we intend to stay there. We do not perform validation, we do not perform effective challenge on our own work, and we offer no opinion on whether our output meets your internal standard. Your second line reviews and your third line audits.
    What can you actually evidence today?
    The only figures we publish about this way of working are our own. Across eight of our own repositories, 326 merge requests were merged. Median time from merge request open to merge was 19 hours. 326 of 326 merged with a recorded approval from a named iTmethods engineer. Measured on our own engineering, 11 July to 11 August 2026, GitLab, release commits excluded, internal environment only, two-person team. The method is written up in full at what we measured. It is not a customer result, and we do not present it as one.
    Which deployment shapes can we have?
    A single-tenant dedicated instance, in your own AWS or Azure account or in infrastructure iTmethods operates. Both are available today, which includes deployment into your own cloud account; Google Cloud is planned for 2027. Air-gapped and sovereign are in development. There is no multi-tenant or shared option at any tier. Deployment options states which is which without softening any of them.
    AWS Advanced Tier Services Partner SOC 2 Type II on Reign Ops
    AWS Advanced Tier Services Partner and Validated Managed Service Provider. Twenty-one years operating regulated engineering environments.
    Next step

    Bring us the change you cannot explain.

    Give us a real population of work with real constraints, and we will run it and show you the record it produces. If your binding constraint is one we cannot meet, we would rather say so in the first meeting.

    Start a conversation Regulatory alignment →