OSFI’s draft Internal Liquidity Adequacy Assessment Process (ILAAP) guideline for deposit-taking institutions is open for comment until August 19, 2026. I submitted four comments — all on Section 3.7, Data, models, validation, and controls, the section on which I believe the guideline’s supervisory value will ultimately depend.
Until April of this year I was the technology manager accountable for retail liquidity regulatory reporting systems at TD Bank Group — a D-SIB regulated by both OSFI and the U.S. Federal Reserve — where I delivered the technology behind NCCF reporting under the LAR Guideline and FR 2052a (6G) reporting to the Federal Reserve. The returns themselves were produced and filed by the responsible business units; my accountability was the systems that produced their figures. The comments draw on that delivery experience, and were submitted in a personal capacity: the views are my own and not those of any current or former employer.
The letter follows, lightly formatted for the web.
1. Clarify whether “other liquidity risk models” includes deterministic regulatory calculation engines
Paragraph 30 expects institutions to “establish strong model governance frameworks for ILST and other liquidity risk models, in line with Guideline E-23 – Model Risk Management.” I welcome this cross-reference; it also raises a scope question that the final text could usefully resolve.
The phrase “other liquidity risk models” inherits an ambiguity from E-23 itself. E-23 defines a model as “an application of theoretical, empirical, judgmental assumptions or statistical techniques … which processes input data to generate results.” The systems that actually produce an institution’s LCR, NSFR and NCCF figures are largely deterministic calculation engines: they implement prescribed LAR rules rather than estimate relationships. In my experience, institutions differ — reasonably — on whether such engines are “models” under E-23, “end-user computing,” or something else, and it is the classification, rather than the engine’s materiality or complexity, that ends up determining what independent verification it receives.
The Bank of England has addressed this boundary explicitly. PRA SS1/23, Principle 1.1(b), provides that “[n]otwithstanding the above definition, where material deterministic quantitative methods such as decision-based rules or algorithms that are not classified as a model have a material bearing on business decisions and are complex in nature, firms should consider whether to apply the relevant aspects of the MRM framework to these methods.” Principle 1.1(c) adds that “[i]n general, the PRA expects the implementation and use of deterministic quantitative methods not classified as models to be subject to sound and clearly documented management controls.”
Suggestion: state explicitly whether the E-23 expectation in Section 3.7 extends to the deterministic calculation and reporting engines that produce regulatory liquidity metrics, or, alternatively, adopt language similar to SS1/23’s — that where such engines are not classified as models, they should nonetheless be subject to sound and clearly documented controls, including independent verification commensurate with the engine’s materiality and complexity. Either resolution is workable; silence will produce inconsistent practice across institutions.
2. Reconciliation to the LAR should state the population over which it is demonstrated
Paragraph 29 expects that institutions “should be able to demonstrate reconciliation to regulatory returns, such as the LAR.” This is the right expectation, but as drafted it can be satisfied by a reconciliation percentage computed over whatever happened to flow through the systems during the period examined — which is silent on the exposures, product types, currencies and contingent behaviours that were not exercised.
A reconciliation figure without its denominator is weak supervisory evidence. Two institutions can both report “99% reconciled” where one has covered substantially its full population of liquidity-relevant behaviours and the other has covered a benign sample. The difference is invisible in the number and is precisely where reporting errors survive.
Suggestion: amend the reconciliation expectation to require that institutions state the population over which reconciliation is demonstrated — for example: “Institutions should be able to demonstrate reconciliation to regulatory returns, such as the LAR, including the scope of positions, products and flows over which the reconciliation was performed and any material populations not covered by it.” This is a documentation expectation, not a new metric. It extends to validation evidence the same discipline BCBS 239 already applies to risk data — that data “should be reconciled with bank’s sources, including accounting data where appropriate, to ensure that the risk data is accurate” (Principle 3), and that reports “should be reconciled and validated” (Principle 7).
3. Tie validation evidence to material system-change events, not only to the annual cycle
Section 3.7 and the Appendix treat data and model validation as components of an annual ILAAP package, and paragraph 34 rightly expects institutions to treat the ILAAP “not as a compliance document but as a living framework” and to update it regularly for evolving risks, market conditions, and regulatory expectations. The gap I would highlight is narrower than the update cadence: neither passage identifies material system change as an explicit trigger for refreshing the validation and reconciliation evidence beneath the ILAAP. The systems that produce ILST inputs and LAR figures change on their own schedule — platform replacements, major releases of calculation and reporting engines, and material data-source changes — and each of these events can invalidate previously documented reconciliation and validation evidence. A platform migration does so most obviously, but a major release of an existing engine can alter classification or aggregation logic just as materially.
OSFI’s existing guidance already contains the hooks. Guideline E-23 (Principle 3.4) lists among the events that should prompt model review “model modifications (including changes to algorithms, parameters, or supporting operational components)” and “significant data changes.” Guideline B-13 (Section 2.5) requires change and release management with documented, tested, approved and verified changes. The NCCF Reporting Manual directs institutions to discuss system limitations with OSFI bilaterally. What the draft ILAAP does not yet do is connect these to the currency of ILAAP evidence.
Migration deserves specific mention because it is the extreme case. When an institution replaces a liquidity reporting platform, the customary evidence is a parallel run with reconciliation between old and new systems. That evidence has the same denominator problem as Comment 2: it demonstrates equivalence only on the behaviours that occurred during the parallel window. Product types, currencies, counterparty classes and contingent outflows that never arose in the window have never been processed by the new system at the point it goes live — and this is where migrations that passed validation fail in production.
Suggestion: add to Section 3.7 an expectation along the lines of: “Where the systems producing ILST inputs or regulatory liquidity returns undergo material change — including platform replacement, major releases, or material changes to data sources — institutions should refresh the affected validation and reconciliation evidence and document the scope of behaviours covered by that exercise, consistent with Guidelines E-23 and B-13.” A cross-reference to B-13 alongside the existing E-23 reference would anchor this.
4. Independence of validation should be demonstrable from records
Paragraph 31 states that supervisory reviews will evaluate control frameworks “with particular focus on how institutions ensure independence and rigor in their validation processes,” and E-23 (Principle 3.4) requires model review to be independent from model development. I support both. My comment concerns evidence: as drafted, independence can be asserted organizationally (separate reporting lines on a chart) without being demonstrable at the level of individual changes.
For the systems in scope of this guideline, the underlying records exist — at two levels that should not be conflated. Independent validation under E-23 is an assessment of conceptual soundness, performance, and fitness for purpose; its evidence is validation workpapers, the identities of the reviewers and approvers, and the record of challenges raised and how they were disposed of. Change control under B-13 (Section 2.5) is a narrower discipline: it requires segregation of duties such that “the same person cannot develop, authorize, execute and move code or releases between production and non-production technology environments,” with traceability of the change record. Version-control and change-management records can support a demonstration of independence — they show who authored and who reviewed each change to the models and reporting engines over time — but they cannot establish it alone, because an ordinary code review is not an independent validation. An institution should be able to show both from its records: that validation was independently performed and challenged, and that change-level segregation held in practice — not only that policy required each.
Suggestion: amend the internal-controls paragraph of Section 3.7 to expect that independence of validation and review be demonstrable from the institution’s records — validation workpapers, reviewer and approver identities, and challenge and disposition records — supported, where changes to the underlying systems are involved, by the change and review records whose traceability and segregation of duties Guideline B-13 already requires.
The common theme
These four comments share one theme: the ILAAP will be as credible as the evidence standards behind Section 3.7. Stated populations, change-triggered revalidation, and record-level independence are all documentation disciplines that operationalize existing expectations rather than new quantitative metrics, and each would sharpen the supervisory dialogue the guideline is designed to support.
Submitted to Consultations@osfi-bsif.gc.ca, August 2026.