Here's a small exercise. Pull up your loan system and look for any non-recourse factoring exposures. Find the field that flags an invoice as past due. Now check what threshold triggers a default classification. If the answer is 30 days, you have a problem — or rather, you're about to.
On 7 May, the EBA published final amendments to its Guidelines on the definition of default under CRR Article 178. Most of the document is confirmatory — the kind of regulatory housekeeping that gets filed and forgotten. But buried in the detail is a change that matters if you run a receivables finance book: the past-due treatment for non-recourse factoring invoices has been extended from 30 days to 90 days. The amendments apply three months after the EBA publishes the translated guidelines on its website — the clock hasn't formally started yet, but assume it's imminent.
That sounds like a technicality. It isn't. It's a data-plumbing job with a deadline, and if your credit systems don't already distinguish non-recourse factoring exposures from other past-due items, you've got roughly twelve weeks once translations land to fix that.
What actually changed
Two things worth knowing from EBA/GL/2026/05.
First, the past-due window for non-recourse factoring. Under the old guidelines, a non-recourse factoring invoice that went 30 days past due could trigger a default flag on the obligor. The EBA has now aligned this with the standard 90-day threshold that applies to most other credit exposures. The rationale is simple: a factoring invoice going 30 days past due doesn't mean the same thing as a drawn facility going 30 days past due. The old trigger was producing default flags that didn't reflect genuine credit deterioration.
Second, the 1% NPV-loss threshold for recognising a default when a debt is restructured. The EBA confirmed this threshold is appropriate and left it unchanged. If you're doing distressed debt restructurings with mid-market borrowers — and most lenders in this space are — this is the confirmation that your existing calibration holds. No action needed on that front.
The factoring change is the one that requires work.
Why this is a data problem, not a policy problem
The policy part is simple: 30 becomes 90. A competent credit officer reads the guideline, nods, and moves on.
The data part is where it gets uncomfortable. In most loan systems I've worked with, past-due flags are driven by a single logic layer that doesn't distinguish between exposure types at the granularity this change requires. The system knows an invoice is past due. It may know the counterparty. It often does not know — at the field level, in production — whether the underlying facility is non-recourse factoring, recourse factoring, or a revolving credit line with an invoice-discounting component.
I'll be honest: I once inherited a portfolio where exactly this ambiguity existed, nobody flagged it, and the first time we found out was during an internal audit. The finding wasn't catastrophic, but the conversation with the audit committee was not one I'd like to repeat. These things don't announce themselves. They sit quietly in your data until someone asks the wrong question at the wrong time.
If your default-flag engine treats all past-due invoices the same way, the 30-to-90-day change means one of two things. Either you keep the 30-day trigger for everything — conservative, but you'll over-count defaults and over-provision, which your finance team will notice. Or you manually override on a case-by-case basis, which works until someone forgets, and then your auditor notices.
Neither is a good outcome. The right answer is to tag non-recourse factoring exposures distinctly in your data model so the default-recognition logic can apply the correct threshold automatically. That's not a policy decision. It's a data-engineering task.
The question worth asking before you scope anything
Can we reliably identify every non-recourse factoring exposure in our loan system today — programmatically, not by asking someone who remembers?
If the answer is yes, the fix is a configuration change. Adjust the past-due threshold for that exposure class, test it, deploy it. A few days of work at most.
If the answer is no — and in my experience it's usually no — you have a classification problem sitting underneath a regulatory change. You need to go back to your facility data, identify which facilities are non-recourse factoring, tag them, and then adjust the threshold. That's a longer job, and twelve weeks is not as generous as it sounds once you account for testing, sign-off, and the fact that half your team will be on holiday in July — which they will be.
When this doesn't apply to you
If your institution doesn't offer invoice finance or non-recourse factoring, this change is irrelevant. Move on.
If you're on the standardised approach and don't use IRB models, the practical impact is smaller — but the definition of default still feeds into provisioning and IFRS 9 staging, so it's worth checking even if your capital calculations aren't directly affected.
And if you're a UK-regulated firm wondering whether PRA will adopt the same change: the EBA guidelines apply directly to EU-supervised institutions. The PRA has historically aligned with EBA default-definition guidance but on its own timeline. Worth watching, not worth assuming.
The takeaway
This week, ask your credit data team one question: can they produce a list of every non-recourse factoring facility in your book, with the current past-due threshold applied to each? If they can do it in an hour, you're in good shape — the fix is a config change. If they can't, you've just found the real project: getting your facility-type tagging to a point where regulatory threshold changes don't require a manual scramble every time. The clock starts as soon as the translations go up on the EBA website.
— Aksel
The Analytical Banker is a weekly note on data, analytics, and AI inside corporate banking — written for finance leaders who actually have to make this stuff work. Reply to this email if something here resonates, or forward it to a colleague who'd benefit.
