Overview

This document will give detail on the feature, how it functions synchronously (validation and API outcomes), how it functions asynchronously (account closure outcomes and notifications) and how the customer record may be impacted based on account closure rules.

Synchronous Account Closure

The synchronous side of account closure is in charge of providing validation for the request that you make. There are 3 main criteria that the request will assess when evaluating if the account in question is in an appropriate state to be closed.

📘

Validation

Below are the validations we apply to account closure. The swagger specifications will be present in our initial January production release but expected behaviours are detailed below with code snippets provided.

Account Balance is zero

As you would expect it is only appropriate to close an account when no negative or positive balances are held. If the account does not have a zero balance the account closure request is rejected.

Held Balance is zero

Similarly to account balance we may find an account that has a zero balance but some funds are held pending the outcome of a payment cycle. If funds are being held these funds will need to complete their processing cycle before this check will be able to pass validation.

As validation context is important we provide a list of reasons in the API response when more than one rule has caused the request to fail as detailed below in the example where both held and balance are not 0.

{
    "result": "FAILURE",
    "description": "Account closure failed. Check errors for more details.",
    "errors": [
        {
            "type": "ACCOUNT_BALANCE_HELD",
            "errorMessage": "Account has 17.78 held balance."
        },
        {
            "type": "ACCOUNT_BALANCE_TOTAL",
            "errorMessage": "Account has 17.78 total balance."
        }
    ]
}

Inflight Direct Debit

Continuing the theme, funds that are in transit may have variable outcomes that can impact the account balance so we do not allow account closure requests to be made when direct debit are awaiting completion.

{
    "result": "FAILURE",
    "description": "Account closure failed. Check errors for more details.",
    "errors": [
        {
            "type": "INFLIGHT_OUTBOUND_DIRECT_DEBITS",
            "errorMessage": "Account has 1 inflight outbound direct entries: [87225f75-9e63-4aa4-9594-8cea4d96e1c1]"
        }
    ]
}

Synchronous Outcomes: Account Status Change

A successful request updates account status for the requested account. This feature introduces a new enum for Account Status (Closed) and if account closure requests pass validation the account status is immediately updated to Closed.

📘

Notification Events

Based on the asynchronous processing you will receive the following Notification events.

Account Status Change

Asynchronous Account Closure

In this section I will provide clarity on all the asynchronous changes that occur when a successful account closure requested is processed.

Cancel PayTo

All PayTo arrangements registered with that account are cancelled.

Deregister PayID's

All PayID's registered to that account are deleted.

Update Cards Status

All cards linked to that account have status updates.

Shaype card status will be updated to Inactive.

Card payment processor Thredd will have an updated status as voided.

Cancel Scheduled Payments

All scheduled payments are cancelled when account is closed.

Cancel Scheduled Events

When the account closure also leads to a customer being moved to Inactive we will cancel all future notifications.

📘

Notification Events

Based on the asynchronous processing you will receive the following Notification events.

Card Status Change

Customer Impacts

Account Closure outcomes can have an impact on the customer record linked to that account. When account closure is being asynchronously processed we have introduced logic that will assess if the customer in question should have their status modified as part of the account closure process.

When is a customer status changed?

When assessing the customer record linked to the account closure we will assess if we believe that customer record is now deemed to be Inactive. The criteria for this assessment is simple.

If the customer is linked only to accounts with a Closed status (once the account closure has been processed) then the customer record is now deemed to be Inactive and their status will be updated to reflect this.

📙

Example: No customer status change

Customer has 2 accounts on the platform with the following statuses

Account 1 - Active
Account 2 - Active

Customer requests to close Account 1

If the request is accepted the status outcomes are as follows:

Account 1 - Closed
Account 2 - Active
Customer - Active

📙

Example: customer status change

Customer has 2 accounts on the platform with the following statuses

Account 1 - Active
Account 2 - Closed

Customer requests to close Account 1

If the request is accepted the status outcomes are as follows:

Account 1 - Closed
Account 2 - Closed
Customer - Inactive

Inactive customer wishes to open a new account

In this scenario we would maintain the old customer profile in the system in an Inactive state to ensure we can keep a suitable audit of that customer profile. In order for a customer who has become inactive to open a new account they will simply need to follow a new customer onboarding journey.

📘

Duplication Checks

When an Inactive customer wishes to onboard for a second time they may need to reuse data that was previously held against their old profile (name, mobile, email or document). In order to allow customers to have access to a second onboarding journey we have updated our duplication logic to filter out customer records that are Inactive.

📙

Example

customerHayId: abc123
email: [email protected]
status Inactive

Customer closed account but has seen a new incentive to rejoin the product offering and wishes to reuse the email previously provided.

When the duplication check assesses their new customer profile and it finds a match on the email it will not fail duplication checks as the email belongs to an Inactive customer record.

Post onboarding the customer profile would be:

customerHayId: def123
email: [email protected]
status: Active

Reason for account closure

We have introduced a new field in the Account Closure API to confirm the reason the account is being closed.

This value is not mandatory but can be supplied to modify how the customer's data is referenced in our duplication checks.

📘

Use Case: Account Closure reason "SUSPICIOUS"

There may be occasions when closing a customer's account is a necessary outcome in managing fraud risk or if there is a concern about how a customer is using an account.

In this instance, when an operational user deems it necessary to restrict that customer from onboarding again the reason for account closure can be set as "SUSPICIOUS" and this will ensure that the customer's data will be flagged as a duplicate if they try to reonboard again with the same details after their account is closed.