IFRS 9 Governance: Automating the Policy



‘Tactical’ IFRS 9 implementations using partly manual/spreadsheet systems are increasingly unacceptable to auditors and supervisors, due to their opaque nature and vulnerability to error. This short article contains suggestions for areas of automation that are practical and will promote transparency and data integrity.

I’ve divided this into 3 sections: 1. The Basics (because not every interested party has had the cause or time to absorb all the relevant nuances of the Standard); 2. The Specifics (because the objective here is to offer real value, based on having been there and done it); and 3. The Value Statement.

The Basics

Many, if not all, of the policy choices made by institutions accounting for expected credit losses under IFRS 9 (the Standard) can be automated, so as to make IFRS 9 governance more efficient and transparent, and less prone to error.

This assumes of course that clear policy documentation exists, authorised at the appropriate level. Policy (any policy) should as far as possible be written to auditable standards, meaning that it should be possible to determine in any given instance whether policy has been complied with, or not (otherwise, what’s the point?)

This is the principle we apply to all Policy/Process documentation.

Your IFRS 9 Policy is also an opportunity to clearly state a few basics that sometimes become muddled, and to equate the IFRS 9 concept of impairment with the regulatory definition of default. Impairment is driven by ‘change in the risk of default’ (IFRS 9, 5.5.9), a wholly counterparty-related concept, irrespective of transactional aspects like collateral, and so aligns well with ‘unlikely to pay [in full, without recourse etc.]’ which forms the basis of the regulatory definition on default.

See also the Standard at B5.5.22: “Financial instruments are not considered to have low credit risk when they are regarded as having a low risk of loss simply because of the value of collateral.”

Since impairment is counterparty-driven, then all exposures to ‘connected’ counterparties should share a common impairment stage (‘connected’ in this context meaning financially interdependent, to the extent that if the aggregate exposure were large enough it would be reported as a single Large Exposure).

There are a few possible exceptions to this, for example for retail assets assessed at the obligor level, defaulted exposures under a certain threshold (commonly 20% of the total); and where a new facility is extended to a counterparty where a significant increase in credit risk (SICR) has already occurred in another facility. But the ‘connected’ functionality can be an optional, user-applied setting in an automated system.

Expected Credit Loss (ECL) on the other hand measures credit risk inherent in the whole exposure. So you can have impaired (Stage 3) exposures with little or no ECL (highly collateralised) and Stage 1 exposures (no default, no significant increase in credit risk) with high ECL (high-risk, uncollateralised products).

The Specifics – some examples

The ‘rebuttable presumptions’ offered by the Standard in respect of determining SICR and impairment, via reference to days-past-due (DPD), can be easily automated. You simply need a system that captures each individual cash flow and its scheduled date (and can therefore count DPD) and which provides for user-defined DPD thresholds for the movement of exposures between impairment stages.

EU institutions (and those in the UK, given that the relevant guidelines have been ‘on-shored’, post-Brexit) will however be mindful of regulators’ dislike of total reliance on such expedients so, for most, an additional level of diligence has been added (again, a matter of documented policy). This may take the form of:

  • an automatically-generated report, for review by a credit officer, listing all inter-stage movements since the last data load. This may be checked for, by way of example only, ‘technical’ arrears (especially in the case of new exposures)’; and/or
  • a comparison of the current PD with PD at origination, so that if the former exceeds the latter by more than a defined level (policy!), SICR is deemed to have occurred (and see the Standard at B5.5.13: “…an entity may use changes in the risk of a default occurring over the next 12 months to determine whether credit risk has increased significantly”).

Conversely, as and when the PD reduces below the threshold, or days-past-due reduces to 30 or below, Stage 1 status can be automatically reassigned.

Inter-stage movements are of interest also because of the required ‘probation’ periods (from 3 to 12 months, depending on the original cause of impairment) before impairment (Stage 3) can be regarded as truly ended, following cure. So we can defer a return to Stage 1 for the required length of time after cure.

All of this functionality requires data, of course – in specific the instance above, for example, we will initially need the reason for impairment (the drop-down menu offers the six reasons cited in the Standard’s definition of ‘credit-impaired’, plus an ‘Other’ catch-all category) and the date/nature of cure. ‘Cured’ status and the date of cure may be entered manually by someone granted the relevant level of authority in the permissioning functionality, or it may be applied automatically according to business rules (policy again!) translated into the data-loading code.  If an authorised user logs a cure and then attempts to remove Stage 3 status before the end of the probation period (whether 3 or 12 months) they will receive a warning message: ‘Proceed’ or ‘Cancel’. If they choose to proceed, then a reason must be offered.

In either case (and this applies to all and any such status changes) the change, the reason therefore, and the officer making the change (if manual, or system/process if not) are captured in the database for subsequent review and audit purposes. The database maintains an immutable and transparent record of the What, Why, Who and When of all such changes, exportable to Excel, PDF, etc. for MI purposes.

Another low-hanging automation fruit is ‘low credit risk’ status (by reference to credit ratings, whether external or internal).

Collateral optimisation is another area where your policy choices can be coded into life, rather than relying on manual processes or opaque spreadsheets – recognition of different collateral types and valuations, and their application to credit exposures based on e.g. risk weights, on/off-balance sheet status and so on, can easily be automated, freeing-up expensive, skilled personnel for more worthy tasks, and reducing the risk of human error.

The Value Statement

Of course there can be errors in the code in production software systems but, once tested and validated, code cannot be changed ‘on the fly’ by an individual user. We all know that spreadsheets can be made secure and can be properly maintained and audited, but the fact is that, generally speaking, they’re not.

Or, as the UK Prudential Regulation Authority puts it “Spreadsheets carry an inherent risk of error because of their vulnerability to over-writing…”

And the cost of human error in the prevailing regulatory climate can be very high indeed.

Automation of your IFRS 9 Policy implies much more than the few examples listed above. The data mapping and data capture development processes provide an opportunity to cleanse and otherwise improve data integrity. Data integrity assurance reports can be generated at each load, highlighting data anomalies, whether ‘fatal’ (exposure cannot be loaded) or non-fatal (just by way of an example, say the Effective Interest Rate is outside a certain range of ‘expected’ values, or the Business Model Classification field is not populated).

High-quality data means that your regulatory report generation can be automated, along with bespoke MI for your ALCO and Board. It will also lay the foundation for the ECL public disclosures called for by the UK Taskforce here, and elsewhere by other authorities.

Perhaps as important as any other consideration, presenting your IFRS 9 governance systems and procedures by way of a tested and largely automated environment, requiring minimal manual intervention, and producing transparent drill-down reporting and audit capability, is the surest way to convince auditors, supervisors and board risk committees that you have got a very firm grip on this critical discipline.


Published by Paul Ashton