*** All Rights Reserved *** Mr Alex Weir, 9 August 2006
find powerpoint slideshow at http://www.cd3wd.com/SPS/SPS_SlideShow.pps
find web version of same powerpoint slideshow at http://www.cd3wd.com/SPS/SpsPPT.htm
find web version of E-Banking for the Elimination of Poverty powerpoint slideshow at http://www.cd3wd.com/SPS/Ebank_Poverty.htm
find downloadable zip file of this document in word plus the 2 powerpoint slideshows at http://www.cd3wd.com/SPS/sps.zip
See http://www.regulateonline.org/content/view/948/63/ for an article on m-banking which includes an interview with the author.
Also - http://topics.developmentgateway.org/ict/rc/ItemDetail.do~1093972?intcmp=3007&itemId=1093972
Low-cost secure
electronic banking for the 3rd world – SPS – SMS Payment System
Version 11 – 21 April 2008 – comment and additional power
point presentation on Universal Income Support Systems (UISS) – see immediately
below….
A year has passed, and no-one has implemented such a system (as far as I know at least), although supposedly the World Bank had some interest in it (I heard this second-hand - they never contacted me). I went to the recent (1-4 April 2008) Africa Banking Technology Conference in Nairobi organized by www.aitecafrica.com , and as far as I can tell, all progress in electronic banking is still firmly aimed at the middle class market, with its attendant moderate or high profitability. Governments are failing to grasp the importance of such low-cost, universal and phone-independent systems, and are ignoring the need to regulate to ensure the supply of the required low-cost/zero-cost SMS’s dedicated to such banking systems. www.fsd.org are implementing income support schemes in Kenya which use old-fashioned high-cost systems and basically disburse US$ 30-00 every 2 months to a family of 5 – they are totally failing to take advantage of what technology is available. I attach an additional powerpoint on my ideas for Universal Income Support Systems (UISS) in the zip file at http://www.cd3wd.com/SPS/Ebank_Poverty.htm and downloadable at http://www.cd3wd.com/SPS/sps.zip - maybe some day someone may pay the slightest attention to such useful concepts…
Alex Weir, Harare, 21 April 2008
***********************************************************************
E-banking is already practiced in many regions of the 3rd world – ATM’s (automatic teller machines), in-supermarket debit card terminals etc exist and are well recognized. Of course, some aspects of e-banking are the preserve of the better-off – e.g. not many ordinary people have home access to a PC, although cyber cafes are pervasive and used by many, especially the urban young.
In much of the 3rd world, financial transactions are best done on a COD (cash on delivery) basis, since often business trust is lacking (for good reasons usually). This can lead to the demand for a large percentage of the money in an economy to be in cash; it can also lead to security concerns (e.g. robbery); and of course governments don’t much like it since it can lead to VAT (value-added-tax), sales tax and income tax evasion. If 2 persons are trying to do such a COD-type transaction without actually using cash, they each need to have simultaneous access to internet electronic banking at the location where they are trying to do the deal, or they each need to be on the phone to a trusted partner, each of whom is physically at a bank (which may be the same or a different bank, depending on how good the banking systems are), or each of whom has access to internet electronic banking.
If inflation is rapid (as it is in Zimbabwe), then money loses typically 5% of its value in 7 days, and conventional use of invoices and cheque payment loses seller and/or buyer huge amounts of money, therefore COD-type transactions become not only desirable but essential.
Most banks in the 3rd world are old-fashioned – it takes between 3 and 14 days to get money cleared from cheque payment; but some 3rd world banks do break that mould – e.g. CABS (Central African Building Society – http://www.cabs.co.zw/ ) regularly move cash around Zimbabwe in a few seconds – pay in cash at one end of the country and withdraw immediately at the other end of the country (or next-door); having said that, even CABS fall down dramatically in their time for processing cheques from other Zimbabwean and International Banks (e.g. Barclays Zimbabwe).
There is opportunity to extend such excellent banking practices to a cashless system – and also to include payments to accounts which are not merchant accounts and do not have online terminals (fixed or mobile network). If such a system could be set up then it opens the window for payments to all kinds of shops and to all kinds of factories, small traders, informal sector, vendors, briefcase businesspersons etc, and also to transfers between individuals and family members.
As mentioned above, there are also significant advantages to such electronic payment systems in economies with rapid inflation, where cash is very much used simply because the value of any and all payments decreases typically at a rate of 5% per week. Admittedly there are few economies in the world which are in this kind of mess (Zimbabwe is one of them).
The requirements would be:
- payment effected by mobile phone sms
- immediate confirmation by mobile phone sms to payer and also to payee
- system proof against illegal interception and diversion of funds/sms’s by persons working at mobile phone providers (MPP’s)
- system proof against illegal interception and diversion of funds/sms’s by persons working at government monitoring stations
- system proof against illegal interception and diversion of funds/sms’s by persons working at the bank itself (especially the IT staff, database administrators, system administrators, programmers etc)
- system proof against false sms’s originated by persons working at the bank itself or their agents or collaborators
- system open to a wider group than merely the typically 5% of the population who own a mobile phone (but do note that in a number of 3rd world countries, much higher levels of mobile phone ownership do exist)
- statement and/or balance receivable by mobile phone sms and also by internet webpage after secure login
- account owner can setup maximum limits to payments to various account numbers (e.g. public utilities – electricity, water, fixed phone, municipal payments), and per transaction and daily and weekly limits (as per normal e-banking accounts)
- payment sms can if required conceal the account numbers of both payer and payee, and also conceal the amount being paid, from MPP’s and government spies
- the necessary encryption and de-encryption is done by the payer (and by the payee) using PIN/TAN secure envelopes and a simple calculator or mobile phone built-in calculator (or even by good old-fashioned pen and paper)
- more sophisticated systems might allow the payer to set up a delayed payment – to be effected at a certain date and time
- more sophisticated systems might also allow payments to be made across currencies, typically from a hard currency to another hard currency or to a soft currency, but probably not from a soft currency to any other currency (with trading zones – like the East African Community – possibly being an exception)
- more sophisticated systems might allow any hard currency element of account monies to be tagged as such, and to be useable to make hard currency purchases and/or transfers (or indeed to be convertible to soft-currency purchases and/or transfers if so wished)
Note that the bank’s records would of course be liable to (legally authorised) inspection by national and international authorities in the event that the account holder is suspected and/or accused of criminal or terrorist offences – despite the emphasis on security in this document, SPS is not designed to be some kind of haven for dirty money, it is just that in the 3rd world, the line between security services/intelligence services and criminals is sometimes hazy or non-existent (in fact not only in the 3rd world!)
A major obstacle to such a system is quite simply the relatively low percentage of persons in much of the 3rd world who own a mobile phone – but that obstacle can be overcome by the SAM concept for receiving sms messages without having to own a phone (http://www.cd3wd.com/SAM/). In any case, if the system response time is in seconds only, then the payer’s confirmation can be received on the same phone as the originating payment sms… i.e. the buyer can use the seller’s mobile phone to make payment (or the seller can use the buyer’s mobile phone to confirm that the buyer’s payment has been received by the seller’s bank account or virtual bank account).
Note that the main attempts to crook the system would involve:
- changing the payee’s account number from that intended to the account number of the thief or an accomplice of the thief
- inflating the amount paid far above the amount instructed
- creating totally false transactions/payment instructions using data read from previous sms payment instruction messages
These attempts can be eliminated by the following:
- encrypting all or most of the payee’s account number using one-time-pad encryption, thereby making it impossible to substitute that account number by another account number
- using an encrypted (again one-time-pad) code to indicate the magnitude range of the payment – this would not eliminate the possibility to inflate the amount but would limit the extent of amount inflation
- the confirmation sms would indicate immediately to an attentive payer that a fraud or attempted fraud had taken place – but this of course would be AFTER the transaction had gone through (if a normal 1-stage payment were made)
- in cases where a call-back transaction is used, an attentive payer would immediately spot the attempted fraud – BEFORE the transaction could go through
- since the system does not allow any TAN Row data to be used more than once, then creating false payment instructions from previous sms’s is impossible – it requires detailed knowledge of the TAN envelope’s contents or of a de-encrypted version of data from the database tables
How it would work:
We assume that in the simple case, all transfers are between clients of the same bank or the same virtual bank (it would be a tremendous marketing push for any bank which opens a good working version of such a system, and indeed it may separate traditional banks into highly automated debit-only banks and separate credit-issuing (and redeeming) institutions). Note also that customers of existing banks may open also an account with the sms bank, which initially has only a relatively small share of their money (and as the sms bank proves itself it may take over business and deposits from the existing bank).
There are several levels and mechanisms of useage:
The merchant terminal automatically supplies the payee account number and the amount to be paid.
The SPS account holder uses his or her TPE envelope to input the following:
- the EUIN (envelope unique ID Number – which the bank’s system tracks back to the payer’s account number)
- the next available unused Row Number (typically 1-20 or 1-50)
- the TAN (transaction authorization number) corresponding to that row number – this will probably be column 3 on the TAN row – i.e. TanCol3.
- Since the transmission from the merchant terminal will be encrypted, then there is no need for additional encryption. A communication back to the merchant terminal from the bank will confirm to the seller and the account holder that the payment has taken place. In some systems, a confirmation sms will be sent to the payer’s phone number or SAM number. This can be largely unencrypted, but will include the EUIN, a vacant row number, and the corresponding TanCol3 number to confirm that it is indeed the bank which is sending the payment confirmation. Alternatively, in other systems, the paper printout from the merchant terminal may be taken as sufficient confirmation (it is for example on conventional plastic-card-based retail transactions).
Note in general that this use of TPE’s and SPS accounts or virtual accounts is quite similar in workings or effect to the new (2006) innovation in developed countries of pre-paid debit cards (PPDC’s) – you buy or get free a plastic swipe card which has a PIN number, and which can be loaded several or many times with money value, and which is useable typically at every retail establishment which uses conventional debit and/or credit cards. This card can also be loaded remotely from the internet, as well as by cash inpayment at a participating bank There may be some ways in which PPDC’s and SPS’s can be integrated, or variations of hybrid products and systems could be conceptualized.
the SPS account holder uses his or her TPE envelope to input the following:
- the EUIN (envelop unique ID Number – which the bank’s system tracks back to the payers account number)
- the payee account number (NON-encrypted)
- the amount to be paid (NON-encrypted)
- the Row Number (typically 1-20 or 1-50). The same row must never be used more than once – if repeat use is attempted then the bank refuses to process, and sends an informative sms to the account holder. Typically the user should stroke out each row once it has been used for a payment instruction or to decode a payment confirmation, to avoid re-use.
- a 6-digit checksum which is composed of:
1. 2 digits from the row itself
2. 2 digits which are to do with the account number
3. 2 digits which are to do with the payment amount
Note that these 6 digits are also in effectively random sequence, as dictated by the TAN-envelope row, e.g. this row may read as follows:
9, LS + 6, 7, A2+3, A7+2, S1+5 which means 9, length of payment sum (number of digits in sum before decimal point) + 6, 7, 2nd digit in account number + 3, 7th digit in account number + 2, 1st digit in payment sum + 5. Note that if the adding process results in a number greater than 9, then only the last digit is taken… and note that digits in the amount are counted from left to right but that digits in account number are counted from right to left…
Let us explain this with an example:
We are paying account 901020377865 with an amount of 200,000-00 currency units, and we are using an envelope 263 999 12345 with row 1 having a set of numbers 9, LS + 6, 7, A2+3, A7+2, S1+5.
The sms reads:
263 999 12345 * 901020377865 * 200000.00* 1 * 9 2 7 9 2 7
And if the bank’s system decides to confirm to you using row 20 of that envelope, which reads A8+1, 3, LS+2, 4, A1+7, S1+9
Then the sms confirmation reads:
263 999 12345 * 901020377865 * 200000.00* 20 * 3 3 8 4 2 1
A similar system is used to send the confirmation to the payee, but that sms will state the account number of the payer also (and of course will state the current envelope number which the payee is using).
the SPS account holder uses his or her TPE envelope to input the following:
- the EUIN (envelope unique ID Number – which the bank’s system tracks back to the payers account number)
- the Row Number (typically 1-20 or 1-50). The same row must never be used more than once – if repeat use is attempted then the bank refuses to process, and sends an informative sms to the account holder. Typically the user should stroke out each row once it has been used for a payment instruction or to decode a payment confirmation, to avoid re-use.
- the payee account number (the last 10 digits of this account number are encrypted using one of the 4 encryption grids on the TPE – which of those 4 grids is to be used is instructed by column 1 on the TAN row – TanCol1 ). This is encrypted in this fashion so that although the sms can possibly be intercepted, it cannot be modified and re-sent on its way as a valid instruction – it will be impossible for any interceptor to guess the encryption necessary to substitute his or her account number instead of the payee’s account number.
- the amount to be paid (encrypted by adding to that amount the number in TanCol2)
- a checksum-type number which indicates the magnitude of the payment amount – i.e. 0-9.99 currency units, 10-99.99, 100-999.99, 1000-9999.99 etc etc, up to 999 million. This checksum is a grid representation of the number of figures before the decimal point. The purpose of this (obviously) is to avoid the value of a payment being raised unduly by any interception and modification process (but the confirmation sms also indicates of course the actual value transferred, or rather an encrypted version of the actual value transferred). Again which of the 4 grids is to be used is instructed by column 1 on the TAN row – TanCol1.
- The tancol3 value from the row is used as a TAN (transaction authorization number).
- The payment is then effected and a final confirmation sms is sent to the payer, which is an exact copy of the original payment instruction plus at the end an unused TAN Row Number and its corresponding TanCol3 Number – that proves to the payer that this confirmation sms has been sent by the bank and not by some fraudster who intercepts and rewrites sms messages. A confirmation sms is also sent to the payee’s telephone number or SAM number, which has (in encrypted form), the payer’s account number, the amount, and the date-time effected. It probably also indicates the current balance in the payee’s account. This confirmation sms to the payee can operate on the simple add/subtract TAN number encryption system, instead of the more secure grid encryption system which is required for a payment instruction. Using this lower-security system, a total of 3 sms’s occur and 2 tan rows are utilized by the payer; additionally 1 tan row is utilized by the payee.
Note that there has to be some mechanism for the payer to inform the bank if he or she suspects or knows that a low-security payment has gone out from his or her account by mistake; at the same time, the payee has to be protected against payers who deliberately make a payment with the intention of trying to fraudulently cancel that payment shortly afterwards. Obviously any and all such exceptions create expensive and time-consuming admin tasks for the bank, and therefore must be charged accordingly – especially since the payer had the opportunity to use a 2-stage callback transaction which is much more controllable than the normal 1-stage payment transaction….
The procedure as per (2) immediately above is followed (except that the payment is not yet effected and that the final confirmation is not yet sent by the banking system). Then the bank’s system responds with the exact message as just sent by the payer, plus also at the end an unused TAN Row Number, and the corresponding TanCol3 number. If the information is OK then the payer replies by sending the EUIN, then repeats that just-sent TAN Row Number, the just-sent TanCol3 number, plus an additional unused TAN Row Number, and its corresponding TanCol3 number. Only then the payment is effected and a final confirmation sms from the banking system is sent to the payer and of course to the payee. Using this callback system, a total of 5 sms’s occur, and 4 tan rows are utilized by the payer plus 1 tan row is utilized by the payee.
Note that for payments above a certain value, this dialback confirmation process will take place before the payment is effected. A default value will exist in the system for this dialback threshold, which can however of course be modified by the account holder (using structured sms with TAN). Dialback payment transactions will cost a little bit more than normal payments. The user will be able to override this threshold to force a dialback transaction for any amount, however small.
The process would be very similar to the merchant terminal scenario as in (1) above. The website would use https (secure socket layer - SSL) protocol to ensure security.
The wide use of TAN’s instead of PIN’s means that falsification of payments by MPP staff or by national security staff is pretty much eliminated, but the neutralizing of insider staff at the online bank requires more care and attention….
Namely, none of the TAN numbers which are printed on the secret envelopes are actually stored as such in the database – encrypted versions and/or checksums of those TAN’s are stored instead – thereby system administrators and database administrators (or their agents or collaborators) should not be able to submit false transactions, since the actual TAN’s are not known to them. Additionally, the incoming payment sms and the 2 outgoing confirmation sms’s should not be stored, so that they cannot be analyzed by the bank’s computer staff in an attempt to crack the whole system. When an incoming payment sms is received, the program checks the encrypted message and/or TAN’s against the encrypted values stored in the database to determine if the requested transaction is genuine or an attempt at fraud (or some mistaken or mis-input data). For software developers reading this, then the necessary database security is ensured by using encrypted stored procedures, which are not visible to or readable by DBA’s, system administrators, and programmers.
By the way, in order to increase general banking security, a person’s account should in fact have 2 account numbers – one is for receiving payments only, and the other is for effecting outgoing payments only – i.e. both numbers designate the same account, but one of the numbers is effectively a virtual account number… Such a system can operate totally independently of any and all electronic banking – it just makes sense that everyone should know your account number so that they can pay you money but no-one except yourself knows the account number from which you make payments…
People who do own one or several mobile phones can increase the security of their system by designating which phone(s) must be used to originate any and every payment sms… But otherwise/in addition they must follow all the normal TAN and encryption steps followed also by non-phone owners..
If the payer or payee does not have any succeeding TAN row left on their TPE then they get back an sms message suggesting that they get a new TPE and register it; after that registration they receive the confirmatory sms’s.
TAN/PIN envelopes (TPE’s) are NOT initially allocated against account numbers – they are randomly produced and distributed. Only when they are acquired by an account holder are they allocated against that account by a structured sms using typically the last unused TAN row on the previous TPE…. On the outside of the envelope is the EUIN (envelope unique identification number). So these TPE’s can be handed around freely by vendors or dispensing machines, since they have no value until attached to an account (which can only be done by the account holder). One can therefore keep a few unopened TPE’s safely unguarded around the house and/or in the car or jacket or trouser pocket.
Worked example:
|
EUIN =
263999123456 |
|
|
|
tancol4 |
|
|
|
tancol1 |
|
tancol2 |
tancol3 |
(subtract
from |
|
rownr |
(use grid
number) |
|
(add to
amount) |
(TAN) |
account
nr) |
|
1 |
1 |
|
789187332813.23 |
123 |
197196 |
|
2 |
3 |
|
118723127631.73 |
273 |
120610 |
|
3 |
4 |
|
982713982731.99 |
463 |
925662 |
|
4 |
2 |
|
761257126531.23 |
827 |
431803 |
|
5 |
3 |
|
817638736221.62 |
922 |
526692 |
|
6 |
1 |
|
817263817321.93 |
588 |
703568 |
|
7 |
2 |
|
716287361823.38 |
673 |
884117 |
|
8 |
4 |
|
176281638123.95 |
892 |
250717 |
|
9 |
4 |
|
187263183223.03 |
642 |
986891 |
|
10 |
3 |
|
127863192311.37 |
811 |
468832 |
|
11 |
1 |
|
198279132112.21 |
956 |
795294 |
|
12 |
2 |
|
871628313287.83 |
021 |
163925 |
|
13 |
2 |
|
192879128332.06 |
893 |
864084 |
|
14 |
3 |
|
128392318123.35 |
961 |
335024 |
|
15 |
1 |
|
198279182318.64 |
548 |
243055 |
|
16 |
4 |
|
192871928322.94 |
627 |
274387 |
|
17 |
3 |
|
198269128312.57 |
753 |
315445 |
|
18 |
2 |
|
198273198373.83 |
018 |
206855 |
|
19 |
4 |
|
192879123239.91 |
936 |
707292 |
|
20 |
1 |
|
182912873923.39 |
857 |
976674 |
|
|
|
|
|
|
|
|
column |
|
|
|
|
|
|
|
amount |
|
|
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
amount |
checksum |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GRID 1 |
0 |
|
447 |
589 |
293 |
644 |
295 |
976 |
773 |
705 |
399 |
312 |
|
|
|
|
|
1 |
|
881 |
353 |
767 |
847 |
479 |
561 |
869 |
484 |
909 |
929 |
|
0-9.99 |
874 |
|
|
2 |
|
725 |
941 |
623 |
749 |
685 |
477 |
581 |
869 |
481 |
111 |
|
10-99.99 |
705 |
|
|
3 |
|
108 |
508 |
237 |
454 |
543 |
127 |
647 |
967 |
727 |
438 |
|
100-999.99 |
884 |
|
|
4 |
|
921 |
131 |
196 |
406 |
130 |
836 |
623 |
681 |
211 |
231 |
|
1000-9999 |
777 |
|
|
5 |
|
179 |
541 |
521 |
382 |
212 |
915 |
844 |
569 |