*** All Rights Reserved ***  Mr Alex Weir, 2013

 

Home

Business and Systems Analysis for a fully fledged low cost e-payment system, done for a client in 2010

http://www.cd3wd.com/SPS/

 

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….

 

 

Postscript – 21 April 2008 

 

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:

 

  1. Using at a merchant terminal –

 

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.

 

 

  1. For low security transactions by SMS,

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).

 

 

 

 

  1. For middle-level-security (low-amount/ high-trust?) transactions by SMS,

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….

 

 

  1. For higher-security transaction by SMS,

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.

 

 

  1. For PC-based payments

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

 

  1. At a merchant terminal:

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.

 

 

  1. A middle-level-security sms transaction:

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.

 

 

 

  1. A high-security sms transaction – using call-back:

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).

 

 

 

 

  1. Can people have a virtual account using this system?

 

  1. Yes – typically the envelope number of the first envelope used can be the account number – this can be established by a structured sms using the first row of TAN numbers….  But also normal accounts can exist in the system.  Even a system can be designed where normal accounts and virtual accounts can both co-exist side-by-side.

 

 

  1. Can users of such virtual accounts convert some or all of their balance to cash?

 

  1. Yes – by using a ‘cash-back’ facility at a participating supermarket, or by a structured sms sent from just outside or from inside a bank premises – the confirmation sms reply gives a CITAN (cash-issuing transaction authorization number) against which cash will be issued for say up to 2 hours following the transaction (otherwise the funds will revert to the account and will require a second or further sms to re-authorize a cash issue).  If this CITAN number were useable in the ATM (automatic teller machine or cash dispenser) then of course the cost to everyone would be lower.  In order to reduce or eliminate the possibility of message interception and fraud, then this CITAN would have to be used in conjunction with the next TAN number on the envelope….

 

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

 

 

http://www.cd3wd.com/SPS/

 

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