Credit account statuses
The account Status enum cannot say that a credit card, finance or mortgage account is in arrears, in default or written off. This proposal adds three statuses — InArrears, Defaulted and WrittenOff — from V2.2, defines each one in the standard, and requires every LFI to return them when they apply.
Cast your vote
Sign in with the Trust Framework to vote — For, Against, or Abstain — recorded in the open with your reasoning. Your organisation and name come from your directory profile, and each person may vote once. Three questions are attached to this vote — set out in section 04 below. Two ask LFIs what they report today and whether the definitions are right; the third asks TPPs how they would use the new statuses.
A status list built for deposit accounts
Every account returned by GET /accounts and GET /accounts/{AccountId} carries a Status (AEAccountStatusCode). The LFI supplies it through its Ozone Connect GET /accounts endpoint. The enum has seven values: Active, Inactive, Dormant, Unclaimed, Deceased, Suspended and Closed.
These values describe a deposit account: whether it is used, whether it has been left unclaimed, and whether it is open. None of them describes the state of a credit facility. The same enum is used for CreditCard, Finance and Mortgage accounts, so an LFI with a mortgage three months behind, or a card balance it has written off, has to report it as Active, Suspended or Closed. None of these is accurate, and different LFIs choose differently.
Three new statuses, defined in the standard
The statuses exist for credit card, finance and mortgage accounts, but are not restricted to them: an LFI MAY use them for any account the definitions fit, such as an overdrawn current account in arrears.
InArrears— an amount due under the account’s terms (a scheduled repayment, a minimum payment, or an amount above an agreed limit) is past due and unpaid, and the account has not been classified asDefaultedorWrittenOff.Defaulted— the LFI has classified the account as in default. This MUST apply no later than the point at which an amount has been past due for more than 90 days, and MAY apply earlier where the LFI’s credit-risk classification does so.WrittenOff— the LFI has written off all or part of the outstanding balance, and the account is not yet closed. Recovery may continue while the account has this status.
- The LFI MUST return the new status when it applies, in place of
Active. An LFI MUST NOT report an account in arrears, in default or written off asActive. - Only one status applies at a time.
WrittenOfftakes precedence overDefaulted, which takes precedence overInArrears.ClosedandDeceasedtake precedence over all three. The precedence between the new statuses andSuspendedorDormantis asked in question 02. StatusUpdateDateTimeMUST change when the account moves into, between or out of these statuses, so a TPP can tell when the change happened.- An account leaves
InArrearswhen it is brought up to date, and the LFI returnsActiveagain. - Confirmation of Payee is out of scope. The CoP
AccountStatuskeeps its current enum, so a payer never learns a payee’s credit standing. An LFI MUST NOT return the new statuses in a CoP response.
What changes
Three enum values, added in the standard and in Ozone Connect. No new fields, endpoints or permissions.
uae-account-information-openapi.yamlAdd InArrears, Defaulted and WrittenOff to AEAccountStatusCode, with the definitions above in its description. This changes Status on GET /accounts and GET /accounts/{AccountId}. Targets V2.2.
Add the same three values to status on CbuaeAccount in uae-ozone-connect-bank-data-sharing-openapi.yaml and uae-ozone-connect-caap-operations-openapi.yaml. CbuaeCopCustomer and uae-confirmation-of-payee-openapi.yaml do not change.
Accept the new values from Ozone Connect and pass them to the TPP on the V2.2 base path. No mapping is needed.
Add the definitions and precedence rules to the LFI Data Sharing requirements and the TPP Data Sharing API Guide, and record the change in the V2.2 changelog.
Three questions, asked with the vote
These appear as optional boxes when you confirm your vote.
Which Status do you return today for a credit card, finance or mortgage account that is in arrears, in default or written off? Can your systems supply InArrears, Defaulted and WrittenOff on GET /accounts by V2.2?
This tells us how these accounts are reported now — as Active, Suspended or Closed — and whether a mandatory requirement at V2.2 is realistic, or whether the data sits in collections systems Ozone Connect cannot yet reach.
Are the proposed definitions right — in particular the 90-days-past-due point for Defaulted? Where an account is both Suspended or Dormant and in arrears, which status should be returned?
The definitions only help TPPs if every LFI applies them the same way. The precedence between the new statuses and Suspended or Dormant is left open on purpose; the answers decide it.
Would you use these statuses, and for what — affordability checks, credit decisioning, debt advice, or something else? Is StatusUpdateDateTime enough to tell you when the account entered the status?
This confirms the use cases the change is for, and whether a later proposal needs to add detail such as days past due or the amount in arrears.
What the statuses buy
- ✓TPPs can see the state of a credit account. Arrears, default and write-off are the facts an affordability or debt-advice service most needs, and today they are hidden behind Active or Suspended.
- ✓One meaning across every LFI. The standard defines each status, so a TPP does not have to infer an account’s state from balances and transactions, bank by bank.
- ✓The change is small. Three values are added to an existing enum; no new fields, endpoints or permissions are introduced.
- ✓It lands with V2.2. Adding enum values belongs in a new version, and V2.2 is still at release-candidate stage.
What they cost
- ×LFIs must source the data. Arrears, default and write-off states often sit in collections or credit-risk systems that Ozone Connect does not read today.
- ×TPPs must handle new values. A TPP that validates Status strictly, or treats anything other than Active as an error, must be updated when it moves to V2.2.
- ×The data is sensitive. A TPP holding a ReadAccountsBasic or ReadAccountsDetail consent will learn that an account is in arrears or in default; the User’s consent covers this, but it is more than the enum reveals today.
- ×Definitions can drift from internal policy. An LFI’s internal classification may not match the standard’s thresholds exactly, and it must map to the standard’s definitions, not its own.