*** All Rights Reserved *** Mr Alex
Weir, 9 August 2006
find powerpoint presentation at http://www.cd3wd.com/SPS/SPS_SlideShow.ppt
find web
version of same powerpoint slideshow at http://www.cd3wd.com/SPS/SpsPPT.htm
find powerpoint of E-Banking for the Elimination of Poverty powerpoint slideshow at http://www.cd3wd.com/SPS/EBank_Poverty.ppt
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 |
930 |
201 |
5
places |
235 |
|||
|
6 |
624 |
430 |
192 |
692 |
443 |
939 |
597 |
910 |
104 |
384 |
6 places |
796 |
|||
|
7 |
511 |
344 |
471 |
332 |
834 |
447 |
724 |
786 |
287 |
230 |
7 places |
671 |
|||
|
8 |
845 |
159 |
973 |
502 |
419 |
594 |
925 |
666 |
592 |
207 |
8 places |
232 |
|||
|
9 |
804 |
833 |
222 |
160 |
635 |
397 |
105 |
836 |
912 |
448 |
9
places |
280 |
|||
|
column |
amount
|
||||||||||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
amount |
checksum |
||||
|
GRID
2 |
0 |
930 |
104 |
378 |
490 |
473 |
755 |
775 |
677 |
599 |
451 |
||||
|
1 |
872 |
595 |
191 |
715 |
220 |
554 |
421 |
161 |
691 |
209 |
0-9.99 |
773 |
|||
|
2 |
335 |
144 |
531 |
725 |
242 |
488 |
140 |
186 |
868 |
814 |
10-99.99 |
306 |
|||
|
3 |
813 |
475 |
317 |
186 |
528 |
638 |
126 |
686 |
666 |
736 |
100-999.99 |
829 |
|||
|
4 |
455 |
446 |
437 |
329 |
981 |
308 |
310 |
412 |
346 |
357 |
1000-9999 |
238 |
|||
|
5 |
557 |
140 |
363 |
324 |
282 |
680 |
761 |
602 |
929 |
801 |
5 places |
963 |
|||
|
6 |
915 |
223 |
194 |
679 |
146 |
489 |
281 |
513 |
202 |
921 |
6 places |
175 |
|||
|
7 |
645 |
154 |
236 |
116 |
943 |
452 |
886 |
347 |
691 |
555 |
7 places |
806 |
|||
|
8 |
929 |
533 |
978 |
290 |
245 |
829 |
867 |
746 |
915 |
689 |
8
places |
576 |
|||
|
9 |
490 |
813 |
182 |
467 |
843 |
637 |
258 |
661 |
513 |
639 |
9
places |
256 |
|||
|
column |
amount
|
||||||||||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
amount |
checksum |
||||
|
GRID
3 |
0 |
317 |
434 |
978 |
732 |
668 |
492 |
610 |
288 |
868 |
363 |
||||
|
1 |
106 |
966 |
328 |
348 |
295 |
616 |
873 |
900 |
238 |
661 |
0-9.99 |
333 |
|||
|
2 |
672 |
950 |
114 |
857 |
551 |
164 |
621 |
610 |
611 |
632 |
10-99.99 |
128 |
|||
|
3 |
178 |
174 |
711 |
710 |
436 |
665 |
579 |
304 |
895 |
577 |
100-999.99 |
924 |
|||
|
4 |
477 |
271 |
904 |
988 |
230 |
482 |
413 |
379 |
121 |
476 |
1000-9999 |
568 |
|||
|
5 |
776 |
894 |
721 |
944 |
769 |
125 |
202 |
732 |
451 |
998 |
5 places |
357 |
|||
|
6 |
537 |
510 |
743 |
654 |
877 |
343 |
626 |
844 |
524 |
577 |
6 places |
664 |
|||
|
7 |
281 |
752 |
932 |
986 |
598 |
250 |
188 |
942 |
523 |
150 |
7 places |
667 |
|||
|
8 |
658 |
974 |
581 |
267 |
886 |
416 |
712 |
755 |
833 |
807 |
8
places |
446 |
|||
|
9 |
190 |
183 |
957 |
264 |
345 |
364 |
998 |
314 |
739 |
460 |
9
places |
865 |
|||
|
column |
amount
|
||||||||||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
amount |
checksum |
||||
|
GRID
4 |
0 |
958 |
329 |
972 |
107 |
874 |
817 |
591 |
808 |
550 |
802 |
||||
|
1 |
302 |
991 |
151 |
454 |
165 |
491 |
968 |
527 |
731 |
941 |
0-9.99 |
959 |
|||
|
2 |
617 |
918 |
850 |
667 |
826 |
379 |
812 |
542 |
132 |
604 |
10-99.99 |
572 |
|||
|
3 |
698 |
762 |
411 |
919 |
360 |
953 |
628 |
818 |
822 |
407 |
100-999.99 |
336 |
|||
|
4 |
615 |
665 |
141 |
414 |
842 |
400 |
133 |
725 |
288 |
506 |
1000-9999 |
936 |
|||
|
5 |
374 |
633 |
552 |
505 |
685 |
585 |
277 |
901 |
272 |
798 |
5 places |
747 |
|||
|
6 |
533 |
614 |
175 |
376 |
157 |
974 |
770 |
315 |
592 |
622 |
6 places |
566 |
|||
|
7 |
662 |
776 |
587 |
599 |
673 |
552 |
655 |
787 |
937 |
752 |
7 places |
259 |
|||
|
8 |
786 |
398 |
330 |
730 |
767 |
434 |
752 |
234 |
514 |
929 |
8
places |
571 |
|||
|
9 |
384 |
261 |
270 |
584 |
792 |
206 |
570 |
166 |
373 |
438 |
9
places |
359 |
We input the EUIN, which is 2639991234. The payee account
number and the amount to be paid are both already in the system ready to be
sent; the payment amount is visible on the screen for you the payer…If row 1 is
not yet used, then we input 1 as the row number, and then the tancol3 value,
which is 123.
We or the till operator press the transmit button, and the transaction
is approved if there are sufficient funds.
The EUIN on the outside of the envelope can also be represented as a bar
code, to speed up the reading process and to guarantee its accuracy.
We wish to pay 956.35 currency units to account number 2639986543
Since row 2 is free then we choose that row.
We input 2639991234 as the EUIN number, then 2 as the row number.
Since tancol1 has value 3 then we use grid number 3 to encrypt the
payee’s account number:
672 510 711 264 345 416 626 732 121 577
Since tancol2 for row 2 is 118723127631.73, then we add that to the
amount:
118723128588.08
Since the amount has 3 digits before the decimal point then we use the
checksum value 924 from grid 3.
Finally the tancol3 value for row 2 is added: 273
Thus the complete sms reads:
2639991234 * 2 * 672 510 711 264 345 416 626 732 121 577 * 118723128588.08 * 924 * 273
We send this to the sps bank service center
number, and shortly a confirmation sms comes back,
which is the same as the sms we just sent, plus some
numbers at the end. If the bank chose to
use row 20, then it sends back:
2639991234 * 2 * 672 510 711 264 345 416 626 732 121 577 * 118723128588.08 * 924 * 273 * 20 * 857
You examine the incoming sms to confirm that
all numbers are as you sent and that the 857 number matches the tancol3 in your
row 20; if so then all is OK and the payment has been made correctly. If the account number or the amount has been
changed then there is some problem, which you will have to raise with your
bank. If you made any mistake in copying
numbers from your envelope then you will probably get some message “your
payment instruction was incorrectly formatted”, and you will have to try again.
We wish to pay 956.35 currency units to account number 2639986543
For simplicity let us assume that row2 is still free, and we choose that
row – the process starts exactly as the case B above:
We input 2639991234 as the EUIN number, then 2 as the row number.
Since tancol1 has value 3 then we use grid number 3 to encrypt the
payee’s account number:
672 510 711 264 345 416 626 732 121 577
Since tancol2 for row 2 is 118723127631.73, then we add that to the
amount:
118723128588.08
Since the amount has 3 digits before the decimal point then we use the
checksum value 924 from grid 3.
Finally the tancol3 value for row 2 is added: 273
Thus the complete sms reads:
2639991234 * 2 * 672 510 711 264 345 416 626 732 121 577 * 118723128588.08 * 924 * 273
We send this to the sps bank service center
number, and shortly a call-back (NOT a confirmation) sms
comes back, which is the same as the sms we just
sent, plus some numbers at the end. If
the bank chose to use row 20, then it sends back:
2639991234 * 2 * 672 510 711 264 345 416 626 732 121 577 * 118723128588.08 * 924 * 273 * 20 * 857
You examine the incoming sms to confirm that
all numbers are as you sent and that the 857 number matches the tancol3 in your
row 20; if so then all is OK and the payment has been setup correctly. If the account number or the amount has been
changed then there is some problem, and you should NOT action the payment. If you made any mistake in copying numbers
from your envelope then you will probably get some message “your payment
instruction was incorrectly formatted”, and you will have to try again.
If all is OK, then you send the action sms –
choose another free row, say number 3, and input also the tancol3 number for
that row:
2639991234 * 20
* 857 * 3 * 463
send this sms
to the sps bank service center number, and shortly
you will receive back the payment confirmation. If they choose row 19 then it will
read:
2639991234 * 20 * 857 * 3 * 463 * 19 * 936
When you receive that it is your confirmation that the sps bank has made the payment.
Now the payee also gets an encrypted confirmation sms
Let us assume that this is the payee’s envelope (the grids are not shown
here because they are not utilized for a confirmation message):
|
EUIN = 2639986543 |
tancol4 |
||||
|
tancol1 |
tancol2 |
tancol3 |
(subtract
from |
||
|
rownr |
(use
grid number) |
(add
to amount) |
(TAN) |
account
nr) |
|
|
1 |
1 |
789187332813.23 |
123 |
817247 |
|
|
2 |
3 |
118723127631.73 |
273 |
102436 |
|
|
3 |
4 |
982713982731.99 |
463 |
252379 |
|
|
4 |
2 |
761257126531.23 |
827 |
300597 |
|
|
5 |
3 |
817638736221.62 |
922
|
699787 |
|
|
6 |
1 |
817263817321.93 |
588 |
427198 |
|
|
7 |
2 |
716287361823.38 |
673 |
532098 |
|
|
8 |
4 |
176281638123.95 |
892 |
681025 |
|
|
9 |
4 |
187263183223.03 |
642 |
693686 |
|
|
10 |
3 |
127863192311.37 |
811 |
934610 |
|
|
11 |
1 |
198279132112.21 |
956 |
185841 |
|
|
12 |
2 |
871628313287.83 |
021 |
727359 |
|
|
13 |
2 |
192879128332.06 |
893 |
723291 |
|
|
14 |
3 |
128392318123.35 |
961 |
887693 |
|
|
15 |
1 |
198279182318.64 |
548 |
304236 |
|
|
16 |
4 |
192871928322.94 |
627 |
457582 |
|
|
17 |
3 |
198269128312.57 |
753 |
383094 |
|
|
18 |
2 |
198273198373.83 |
018 |
299694 |
|
|
19 |
4 |
192879123239.91 |
936 |
602832 |
|
|
20 |
1 |
182912873923.39 |
857 |
343520 |
|
Note that to be lazy, I have used the same
numbers as for envelope 263 999 1234 (that will never happen in
practice!). Also that throughout these
examples I am confusing the EUIN with the account number – but never mind…
The incoming confirmation sms for payee will read:
Payee’s EUIN * EUIN Row Number * Payer’s account number (encrypted) *
amount paid (encrypted) * payee’s EUIN Row Number Tancol3 value
If we choose row number 1 from EUIN 263 998 6543, then the sms reads:
263 998 6543 * 1 * 2639173987 * 789 187 333 769.58 * 123
Note that the account number has the tancol4 subtracted and that the amount
has tancol2 added.
From this sms, the payee can work out that
956.35 currency units have been received from account 263 999 1234…
Some FAQ’s
(frequently-asked-questions) follow:
Q.
It seems that the latest changes to the system
make it very complicated to use?
A. Yes – methods 3 and 4 are probably
too complex for normal users, and should probably be used only by business
persons – but that is the price of having a secure system using sms (which is a totally unsecured medium), and also for
operating in an environment where those capable of reading and re-writing sms messages are also quite liable to succumb to the
temptation to do so for monetary gain.
But the method (2) is relatively simple and
useable by an ordinary account holder with a little training.
At least the merchant-teller-based
implementations of the system are relatively simple, as are the PC-based
implementations of the system. Therefore
when the first SPS or SPS-like system appears, maybe it will only have those 2
features; or maybe a cut-down but less secure version will be rolled out; or
the secure features for non-merchant/person-to-person transactions and payments
will be present but will be unused by the majority of sps
account holders.
Note that the addition of technique (2) as
above for low security payments is the magic bullet which simplifies the
operation while maintaining a high level of security. The main advantage of this method is that
everything is pretty simple and difficult for the payer to get wrong; the main
disadvantage is that everything is readable by mobile phone providers and by
intelligence services (and therefore by intelligent crooks). However, it is very difficult or impossible
for these groups to modify the payment sms to
something which will be recognized as coherent and legitimate by the banking
system. Therefore this technique (2) is
actually the main technique which will be used by account holders (apart from
the merchant terminal method or PC-based method, which are even simpler).
Some SPS operators may choose to have no
branches whatsoever, and to rely totally on cash-back by supermarkets and other
retail establishments and chains, and/or on using the ATM’s of ‘real’ banks or
building societies. This could open the
possibility for one or several global automated SPS operators…. Such operators would allow bi-directional
money flows between hard currency countries, but only uni-directional
money flows from hard currency to soft-currency countries (and no money flows
between 2 soft-currency countries).
Q, How is SPS funded?
A.
A
small fee is levied for each sms, equivalent to the
actual cost of the sms plus a small margin. Actual cost of an sms seems to be about zero but lowest charges are typically
US$ 0.02. Therefore each transaction
could cost about US$ 0.06 (since there are 3 sms’s –
one originating and 2 confirmatory).
If charges were actually so high it would negate many of the benefits of
SPS for micropayments, so we have to hope that MPP’s would get into the game
and discount sms cost below the US$ 0.02 limit. Possibly for SPS’s to succeed in a country
environment, the charges made for cash issuing would have to be
equal to or higher than the charge for an electronic
transaction. Typically, cash issuing
charges seem to be in the region of US$ 0.03 – US$ 0.10 for small amounts (up
to US$ 40-00), and maybe 1% of value thereafter. While we are discussing the economics of SPS,
note that the mass production of TPE’s costs about US$ 0.20 per envelope; if
there are 20 TAN rows per envelope then the cost per transaction for envelope
use would be US$ 0.03 (since 3 envelope rows are used for a method (2)
transaction), or US$ 0.01 for merchant terminal or PC-based transactions, which
use only 1 row. If the TPE’s can be
printed with 60 or more rows, then the envelope component of unit costs
reduce…..
SPS is also funded by making
interest on overnight deposits, although a good SPS would also pay out
interest, especially in a hyper-inflationary environment.
Q. How does one get cash INTO as SPS account?
A. This could
also be done through the reverse of a supermarket cash-back system – pay cash
or excess cash in at a supermarket till and have it credited to your SPSAN (sms payment system account number), with a computerized
till slip as the receipt. Alternatively,
through the tellers of ‘real’ banks which have a collaboration agreement with
the SPS. Additionally by credit card payment, debit card payment, internet
banking, transfer from ATM, cheque, and all kinds of
‘normal’ payment methods. Also ‘real’
banks may choose to run (or to subcontract out or franchise) SPS accounts
alongside their conventional accounts, making it also very easy for their
customers to transfer monies between the normal and the SPS account.
Q. Will
SPS have any credit facility?
A. My
instinct on this is no – never. As
mentioned elsewhere, if people need credit let them go to a separate credit
issuing and redeeming institution. But
if the intention is that SPS will complement and even integrate with some
microfinance scheme, then possibly SPS could include such capabilities,
including automatic staged repayments (with sms
advance warning of impending repayment due and sms
statement of outstanding amount)
Q. Can
an SPS payment be made to include also a seller’s reference number? (SRN)
A. yes – this would typically be an additional
field in the structured payment instruction sms. This could for example be the reference
number for a shopping basket of goods or services which has been set up on the
internet through a phone call, or over the counter. The shopping basket is freighted, couriered
or released once
a (correct amount) payment with the reference number has been received.
Q. Could SPS have any positive developmental
impact?
A. It
could assist in microfinance schemes – the widespread ownership of bank
accounts or virtual bank accounts could greatly lower the cost of issuing loans
and making repayments. And by utilizing
the SAM (http://www.cd3wd.com/SAM/)
concept and system, microfinance schemes would also have very low-cost means of
contacting the borrowers and of sending them reminders, statements and other
communications.
It could also bring liquidity to more remote
areas which are far from normal banking facilities – the funds could go round
and round, often without being converted into real cash. Of course they have to have mobile phone
coverage, but that is a requirement for electronic voting, which might be
funded directly or indirectly by donors (see http://www.cd3wd.com/SEEV/).
SPS could bring donations to a person-to-person
level – a concerned person in a developed country could directly transfer cash
to one or several recipients in one or several 3rd world countries,
and thereby by-pass all the local and international NGO’s which normally
swallow 80% of the donation en route. Of
course there would be con-men and con-women who would try to take advantage,
but there would be ways of identifying them and informing the donor(s).
Q.
What
infrastructure is required for SPS?
A.
Very
little – conventional MPP (mobile phone provider) infrastructure, including
databases, with some additional software only.
The bank balances and bank transactions are kept in database records. SPS’s would be set up sometimes by MPP’s and
sometimes by existing banks, other times by Joint Ventures between existing
banks or building societies and MPP’s.
SPS’s could even be organizations independent of existing banks, building
societies and MPP’s. It is possible for
an SPS to utilize and rely on an external sms-to-email-to-sms or sms-to-webservice-to-sms gateway provider so as to minimize the required direct
investment by the SPS operation. That
gateway provider can even be one of the national MPP’s or can even be an
external/international service provider.
Q. Do you have any additional special
value-added features in mind for SPS?
A. Yes –
one of these is a quasi-escrow account facility. Effectively if the production of a good or service
is being commissioned, and the producer does not totally trust that the buyer
will have the necessary funds to pay for the product or service when it is
complete, then the buyer can designate a certain amount of the funds in his or
her account as escrow funds to be held
for a variable time period; the seller receives an sms
to that effect, and if at any time the prospective buyer cancels that escrow
arrangement, then the seller receives an sms
informing him or her of the cancellation.
This could be done also in conjunction with a non-refundable deposit, or
it could simply be done by a more conventional proper escrow deal through a
normal bank, without any SPS quasi-escrow facility.
Q.
How
would VISA and Mastercard feel about SPS’s?
A. I
guess they would be afraid – how would the oil companies feel about alternative
energy which is less expensive than oil? – it is a
similar reaction. Please note that SPS
is not simply designed to be some second-rate banking system for the poor, it
is a high quality general solution for all sectors of society, individuals and
business. Price competition from
SPS-like systems against Visa and Mastercard may
cause them to lower their exorbitant charge rates.
Q.
How would conventional banks in the 3rd world feel about SPS?
A. They
would also be quite negative I suspect.
SPS would accelerate the existing decline of conventional (and usually
inefficient) banking operations in the 3rd world. But, as mentioned above, SPS’s may create a
trend to separate banking (debit banking) and credit provision (and
redemption).
Q.
Does the SPS concept have any place in developed countries?
A. Why not. Banking is banking. Especially the ability to make money
transfers to non-merchant accounts is quite attractive.
Q. Are there any other independent papers
on electronic banking for the poor?
A.
Check http://www.cd3wd.com/SPS/ebanking.pdf by David Cracknell
of http://www.microsave.org/
Q. How does one organize payments in a market
economy with more than one SPS?
A. The
account number of the payee also specifies the SPSP – the SPS provider – i.e. account
numbering is controlled between SPS’s and there are no duplicate account
numbers. In fact, best if SPS’s operate
a global account numbering system (similar to internet IP addresses), since if
and when SPS’s take off then their reach will very quickly become truly
global. And if a payment is being
commanded from an account holder in SPS1 to an account holder in SPS2, then the
communications gateway between SPS1 and SPS2 will kick into action and
authorize or negate the transaction. The
confirmation sms to the payee could come either from
SPS2 or from SPS1, according to the convention adopted.
Q. What are the main advantages of SPS over
existing mobile banking solutions and proposals?
A.
1. Security – if the mobile phone
is stolen, then the account and the funds are totally safe; conversely, the TAN
envelope becomes the key to safeguarding monies; note here that the account
owner can make a paper copy of their TAN envelope and destroy the original –
and the paper copy can have some further simple encryption method (effected by
the account holder), such as all numbers increased by a value of 3 (or
something more complex)…
2.
For
areas with relatively low phone ownership (typically 5% of population) then SPS
has great advantages.
3.
Again
security – SPS is hacker-proof; of course there are measures (best not
discussed in this or any paper) which have to be taken at the database
administration and security side – but that is normal in any and every banking
operation of any kind.
4.
All
the technology to implement SPS exists and is tried and tested; moreover since
it utilizes conventional sms with no bells and
whistles, then the global market for SPS is huge (and the sms
standard is likely to remain in perpetuity – we must hope – unlike other
standards which sometimes are superceded and/or fall
by the wayside).
Q. What
about the technical feasibility?
A. The company Mobilearts
of Sweden (www.mobilearts.com) have reviewed this project in principle and are reasonably
convinced that it is technically feasible. Moreover they have the
technologies to implement this project for an international client
Q.
SPS
seems amazingly simple – why has no-one else thought of it already?
5.
I
am trying to work that one out myself.
Actually SPS is the 3rd of my sms-based
concepts/innovations over the period 2006/05 through 2006/08, and really
although all 3 are simple and have a lot of commonality, none of them were ever
really obvious; and I have been thinking about and conceptualizing low-cost
communications for the poor (http://www.cd3wd.com/SAM/)
since 1995, government-proof voting systems (http://www.cd3wd.com/SEEV/) since 2002,
and micropayment systems (http://www.cd3wd.com/SPS/)
since 2000. Maybe also part of the
trouble has been that many conceptualisers in the
field of mobile banking have been technology-driven and producer-driven,
instead of being consumer-driven. Indeed
the SPS concept is quite difficult to patent, since all the components exist
already – all the technology to implement SPS exists and is tried and tested.
Q.
As the inventor of SPS, how do you propose to make money from it?
A.
By a levy of US$ 0.0001 per SPS transaction made anywhere globally –
this would be about 0.17% of the anticipated charge for each SPS transaction
(US$ 0.06). The exact amount could be subject
to negotiation with each SPS, and would depend also on expected and actual
number of payment transactions.
PS – note
that the SPS concept can have a wide variety of interpretations and
implementations – it is a flexible concept which can adapt to the marketplace
and to the needs of security for the customers and for the operators. But the basic principals are extremely sound
and offer tremendous advantage to service provider and to service consumer.
Find a
Microsoft word document of this webpage at http://www.cd3wd.com/SPS/sps.zip,
from where it can be downloaded and unzipped.
Mr Alex
Weir
4 Brechin Drive
Harare
Zimbabwe
Africa
Tel +263 4
301 047
Tel +263 23
824 045 (mobile)
http://www.cd3wd.com/contactus/
P.S. some
technical terms:
ATM -
automatic teller machine – cash dispenser
DBA –
computer database administrator
EUIN –
envelope unique identification number
MPP –
mobile phone provider
PIN – personal
identification number
SA –
computer system administrator
SPS – sms payment system
SPSAN – sms payment system account number
SPSP – sms payment system provider or operator
TAN –
transaction authorization number
TPE –
TAN/PIN envelope
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
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
downloadable zip file of this document in word plus the powerpoint
slideshow at http://www.cd3wd.com/SPS/sps.zip
*** All Rights Reserved *** Mr Alex
Weir 21 April 2008