Did We Score an Own Goal with NUBAN?
For a while now, I’ve been silently curious about the way NUBAN was implemented in Nigeria; but recent emails about wrong transfers using NUBANs have heightened my concern. Taking steps back to years leading to 2010 when CBN circulated this policy, there was a spike cheque presentations at the ACH (central clearing house where bank cheques are exchanged for settlement daily); with this came attendant complaints of wrong beneficiary account number specified by customers, and settlement into wrong beneficiary accounts by clearing officers, among many others. It is worthy of note that at this time, all the twenty four Deposit Money Banks (DMBs) in Nigeria all had different account numbering nomenclature.
All these led to the CBN policy that introduced the NUBAN (Nigeria Uniform Bank Account Number).
So the objective of NUBAN was clear from the onset — to allow payments happen in a unified way across DMBs. It was specifically aimed at helping to “resolve the observed problems with electronic payments in Nigeria, as many of them were related to specification of wrong beneficiary account numbers.”
Systemically, implementation followed policy formulation.
So that we do not reinvent the wheel, here’s the CBN paper that explains the implementation algorithm for generating NUBAN.
In computing a NUBAN, there are three key components, briefly described below:
1. The 3-Digit Bank Code: Before NUBAN, the 3-digit bank code was the most important parameter for inter-bank transactions (clearing system), as systems will understandably deal with numbers / integers as against letters / text. If we tried text with systems, Nigerians will respond with things like GTB, GTBank, GTB-Bank, GT, Guaranty, GTY, etc. to represent Guaranty Trust Bank for instance. On the other hand, restriction to 3 letters will equally be problematic because customers will have challenges accurately representing Unity Bank and Union Bank; and Skye Bank and Sterling Bank and you can’t control human intervention.
2. Account Serial Number in the Bank. This element of the NUBAN combination gives it “body”. This helps to create the sequence for the NUBANs. Typically banks just run SQL selects statements based on date (time stamp) of account opening in the bank.
3. Check Digit. As with most algorithms, you need an independent variable that checks the validation of computations and eliminates duplicates. Most importantly, it’s difficult, if not impossible, to work backwards with randomly generated numbers; so to have some structure, we create formulas using independent variables also known as check digits.
With all due respect to the hard work and research that produces this computational algorithm; my curiosity however, has been about whether there could have been simpler ways to achieve the same thing. The tiny challenge with the current NUBAN structure is that we have cases of the same NUBANs occurring, howbeit in different banks. This is both mathematically possible, and has a higher chance of occurrence as more NUBANs are generated. My suspicion is that 85% of banked customers (in this context, persons making banking transactions) are not aware of this possibility, or fact as it were.
From where I sit, I hear about and sometimes get involved in multiple instances of “oh please I sent money to the wrong beneficiary, the account number is correct but I just selected Bank A instead of Bank B” daily; in most cases Banks A and B start with same letters or even same first words. There is the temptation to quickly blame the user; but User Experience 101 tells us that “if you leave the door open, the user will walk through it”. This is even more prevalent in bulk payment systems (I have a great deal of experience with this) where customers have to populate an upload file and supply 3-digit bank codes and NUBANs in separate columns (among other details e.g. amount, remarks, payment dates, etc.). From experience, non-sophisticated users mostly sort the records by bank, and then either do a copy and paste, or hold+drag the first 3-digit bank code record for a set of records of a bank, till the set of NUBANs for that bank is covered. The chance to drag beyond the records of the applicable bank is well more than 50% given that the succeeding record(s) start with same letters or same first words.
APIs have helped a bit (how I love system integrations); and may well provide our surest mitigation against this challenge given the complexity of restructuring NUBAN as an option. However, with the current structure, even when you build interfaces around bank selection (tied to 3-digit bank codes backend); users still select closely related bank names erroneously as we breeze through the day as Nigerians.
I thought NUBAN was our chance of having a truly unified, and unique account numbering system, using the three key components described earlier. I recommend that this challenge can be addressed as described below:
The drawback of this proposition is that customers now have to remember 13 digits as against 10 digits; but a quick sampling revealed that most banks, in the years preceding 2010, provided customers with account numbers of 12–15 digits. A more daring approach is to reduce the 9-digit serial block and hope that given the fast pace of payment system infrastructure and innovation development in Nigeria; consumers will reduce duplication of records at different banks as service offerings become standardized and the need to switch banks remain low. We can bet on not exhausting the serial blocks before disruptions like block chain become mainstream and ledger banking remove the need for multiple bank accounts.
What are your thoughts?