Handling Back-dated Transactions and "Online" Transactions on ERP/Banking Systems

Question

I was currently developing a PoC of a "core banking system" in my current company, a pawn shop that generally offers lending services to retail customer and deposit services. We've built a legacy system since 1998 using FoxPro DOS and this year we have successfully rewritten our platform using Java Spring Boot. As time goes by, our management started to introduce development plans for "electronic banking" platform, such as mobile apps for customer, which include some features like account inquiry, deposit withdrawal to bank account (integrating with payment gateway service), online loan repayment, etc.

Our current system depends heavily on daily "end-of-day" batch process, which include computation for: generating daily trial balance from journal entry, standing instruction for loan repayment via deposit account, daily accrual and amortization computing, etc. Our system also has a separate "system date", that were different with the actual date. The system date was incremented after end-of-day process and was skipped on public holidays and Sundays.

As we introduce our mobile services, we started to have some problems on integrating the platform with our "core banking system", like: The deposit withdrawal feature on mobile apps where achieved by integrating our system to bank's API, where we deposited some funds (nostro account) to that bank, so basically when a customer withdraw their deposit, the system will generate this journal entry (Dr. Customer Deposit A/c, Cr. Nostro Account). Due to regulatory requirements, we must reconcile our nostro account so the balance stated on bank's statement was same with the balance shown on our system. This reconciliation process sometime takes one day to be done, so it must be done by doing a back-dated journal entry. As we were generating trial balance daily on the batch process, back-dated entry would be tricky because we must re-generate the trial balance from the entry date until current "system date". Have we done the right thing on handling this case? Because the another method that would make this back-dated transaction easier was to remove the "trial balance" table and calculate account balance on the fly every time it was needed, but on the long run the account balance inquiry will getting slower as the number of rows of the journal entry increases

While integrating the transactional features on the mobile apps to the "core banking systems", currently we inserted the transaction to a separate database for the mobile apps API and asynchronously create a journal entry in the core system related to the transaction (for example, for a repayment transaction, the journal will be Dr. Nostro Account, Cr. Loans and Cr. Interest Income). Is this a common way to integrate a mobile banking app to the core banking systems? Related to the reconciliation process, should we do all the mobile app transaction journal into a separate suspense account, and move the suspense account balance to the nostro account upon daily reconciliation process? I think this method would also apply if in the future we would introduce some integration into card network system or ATM system.

I've searched for some resources on the internet related to this topic, but unfortunately there aren't many resources that discussed about this, i think because some of it were involving "secret sauces" of each institutions. Thank you in advance for your kind help :)

Answer 1

It's a great question, and one that reveals many of the subtleties about banking that we rarely see here.

I can't answer all the questions, but I can say something on a couple which involve fundamental issues.

Back-dated entries

Due to regulatory requirements, we must reconcile our nostro account so the balance stated on bank's statement was same with the balance shown on our system. This reconciliation process sometime takes one day to be done, so it must be done by doing a back-dated journal entry. As we were generating trial balance daily on the batch process, back-dated entry would be tricky because we must re-generate the trial balance from the entry date until current "system date". Have we done the right thing on handling this case

In "core banking" in general, I'm led to believe there is no such thing as a back-dated entry. That is, the entries showing from a previous business day can never be altered retrospectively. The same day's entries can be stricken, but not the previous day's.

I'm also led to believe that banking regulations require bank accounts to be settled on a daily basis (as the bank defines its business days), so that once the bank reopens for business on a following day, the accounts of the previous day are fully settled and fixed forever.

As an aside, the purpose of "bank holidays" has always been to give banks collectively the occasional power to take longer than a two-day weekend to get all their accounts in order (including the accounts they keep between themselves) and ready themselves for the next business day.

From the point of view of generating daily balances, entries on following days should never affect the balances on previous days.

You can of course store auxiliary data showing how a particular entry relates to an event in the past, but from an accounting point of view, the entry has effect on the accounting system on the day it hits the account, not retrospectively.

So I think you've potentially gone wrong by making entries that affect previous day's balances, if your system is written around the principle of generating balances daily overnight.

I'm not sure whether your system has to be written around that principle. You may come under financial regulations, but I assume that you are not actually a "bank" legally speaking.

For example, rather than each day's accounts being settled at the end of each day, they could perhaps be settled at the end of the following day, giving you an extra day to reconcile the information you receive from your bank.

Incidentally, the reason for the concept of an "unauthorised overdraft" is because there are things in flight which may affect the account but have not yet been entered, but must be entered when the information arrives and cannot be rejected (because it reflects entries or facts elsewhere which are already final).

Implicitly the bank has to be prepared to extend credit to account holders as part of keeping its accounting system in proper order, even if it does not want to extend credit, and part of running a bank involves having to bear and manage this credit risk.

It's also why credit cards have the concept of "exceeding your limit" - the limit cannot always be enforced, because of in-flight transactions. The system having been designed in the era when most things were still done on paper, and still potentially required to operate in offline mode when modern telecoms go down (such as in a national catastrophe or war, as well as during more routine breakdowns and maintenance outages).

Summarising and archiving data

Because the another method that would make this back-dated transaction easier was to remove the "trial balance" table and calculate account balance on the fly every time it was needed, but on the long run the account balance inquiry will getting slower as the number of rows of the journal entry increases

You'll almost certainly find that you will eventually need to remove data from your system, and generate summary balances to cover purged entries. Certainly, it would be foolish not to incorporate this facility.

The original purpose of a "bank statement" was not just as an account listing, but to be a legally-binding statement of the account and a balance to carry forward, which if not challenged would become binding on the customer, and the bank could then throw away all internal information relating to and justifying previous transactions (so that it did not eventually become snowed under).

If your system is (or will be) quite heavily loaded relative to current technology, you might also find that ordinary operations require you to work from summary balances carried forward, even if the transaction-level data is still available.

My advice would be to continue generating summary balances in a suitable way, and never assume the continued existence of all transaction data from the opening of the account.