Initially, the CRB banking core, COS, allowed XPay transfers from one checking account to another. Arix however, needed a solution to be able to send funds from a General Ledger (GL) account to the partner’s checking account.
A GL is the account type used to create assets (loans) on the banks' books.
To solve that, we introduced a bridge checking account. Every disbursement via the XPay rail consists of 2 legs in COS:
- An internal transfer from the GL to a bridge checking account
- And then an XPay from the bridge checking account to the partner’s checking account.
Example of the old 2 leg XPay rail as returned in Get /LoanDetail
This solution worked well for the last year and a half but every once in a while there were some glitches.
Due to the async nature of CRB systems, non-sufficient funds (NSF) in the bridge account could occur at rare times and cause the XPay rails to fail the 2nd leg, as it could not pull the money out.
CRB and the MPLs wasted time identifying the issues and coming up with fixes and the Ops teams would have to make manual transfers and reversals, and support manual data fixes. That’s right, manual - for a rail that is expected to work 24/7.
COS now allows direct XPay from GLs to checking accounts and now Arix does as well.
Example of new XPay rail as returned in Get /LoanDetail
We also revamped XPay reversals.
If an MPL checking account is configured to allow CRB to pull from it, a return will result in an automatic reversal of the XPay rail. In that case, no manual operation is needed from the Ops team and the reverse is immediate, allowing you to request a new rail without delay.
If an MPL doesn’t allow funds to be pulled from their account, the process will stay like it is today. The loan will stay in InReversal until the funds are manually reversed.
If you’re an MPL that’s already using the XPay rail, your experience will be even better now.
Updated over 1 year ago