4 years have passed since I wrote the original specification for SPS (sms payment system). As far as I know, no one implemented such a system. I myself was busy pushing the much more important SEEV Voting System, and also between times making a living working and avoiding the unwanted attentions of at least 2 International Intelligence Agencies.

Now technology in particular has changed much – the very large proportion of populations of even very poor Third World Countries which have a basic mobile phone, and also the rapidly tumbling price of high-quality durable and reliable internet-enabled mobile phones . Thus essentially it is now time to jettison the SMS (text message) model and to switch to a normal internet web browser model using a mixture of low-cost smart phones, PC’s, POS machines and other devices.

This document is in fact about 5 documents in one – it starts with a high level outline and then moves through various aspects of the nuts and bolts of creating a suitable system for Mobile Banking or Branchless Banking or Cashless Transfers. These systems are designed to be closely integrated with Social Payments (sometimes called G2P or Government to People Payments) and also with that old chestnut – Microfinance.

This document does not yet go down to system programming level – that is the next stage – but just about everything above that level is detailed (Ok – the required database structures are not detailed here either). It would be preferable to have one implementation which is rolled out globally, so maybe this document is inviting commercial and/or government and/or donor interest in funding the creation of such a system. That system itself will have several options and will be quite highly parameterised (language and RTL capability will be only one of the parameterised areas).

The major design intention of such a system is that the charge per transaction will be in the region of US$ 0.03 (and not the outrageous and completely unsustainable US$ 0.30 per transaction as is practised by almost every existing mobile banking system). *** Note that use of this system necessitates a royalty payment of US$ 0.0001 per transaction payable to me, Alex Weir, and/or my estate ***

Although this document is available under http://www.cd3wd.com/SPS/ then it is in fact no longer SPS – there is no planned SMS/Text Message functionality. I don’t yet have a suitable and sexy alternative name for the system, so SPS2 will have to do for now – my apologies.

Finally, the original sps document still has a lot of relevant stuff – find it at http://www.cd3wd.com/SPS/sps_original.htm . Find a powerpoint of sps2 at http://www.cd3wd.com/SPS/sps2_ppt.pdf , and a zip file of various files at http://www.cd3wd.com/SPS/sps2.zip

Mr Alex Weir, Harare, 7 September 2010 - http://www.cd3wd.com/contactus/

PS – note that the documents below were written in date sequence. There is some duplication and overlap within the documents. Where there is contradiction, the later document applies.

Electronic Banking and combating poverty worldwide

By Alex Weir, 21 June 2010, Harare

Imagine a situation where everyone in the world over 18 (plus orphans and street kids under 18) has a bank account which can even be used in remote rural areas of the third world to buy food and other things and also to receive payment for work, for sales of produce etc..

This bank account, thanks to modern technology, is extremely low cost, averaging maybe US$ 0.03 per transaction.

Although there are countries with very high penetration of mobile phone usage, the bank account can operate without the account holder needing to possess a mobile phone.

The bank account system can even be extended simply to be also a communications channel not only from the account holder, but more importantly TO the account holder. When one checks bank balance one can also receive messages from personal and business contacts (and from Government, Donors and NGOs)

Such a bank account system can be termed a Virtual Bank Account (VBA), but there is in fact nothing virtual about it. The contents of a VBA can be converted to good old fashioned hard cash, and hard cash can be used to put money into the VBA. However whenever transformation into hard cash or into a ‘real’ bank account takes place, the costs usually escalate from the very affordable US$ 0.03 per transaction to something in the region of US$ 0.30 per transaction. Therefore ideally such a system works best when only the few at the top of the pyramid – supermarkets and food wholesalers amongst others – actually on a regular basis convert their VBA holdings into ‘real’ bank deposits.

To reassure the reader, every penny in the VBA’s is matched with a corresponding balance in a ‘real’ bank account – except that maybe 1 million VBA’s may be fed from one single ‘real’ bank account.

Imagine one very important refinement is also added to this VBA system – the capability for any person putting funds into one or many VBA accounts to specify limitations governing the use of those monies – e.g. food, agricultural inputs, water, electricity, property taxes, school fees, school textbooks, medicines, doctors’ fees, building materials, or any combination of these. Retail outlets and service providers register one or several VBA accounts with the VBA system as for example an account which only receives school fees. Then a normal account holder can pay that school with monies from their VBA account using either general (unlimited) monies and/or monies (if any) which are flagged in the account as being monies limited to paying school fees.

This then enables (at least in theory) family, relatives, NGO’s, Donors, Governments, etc to target micro-grants or microloans to be used for specific purposes. Such a system could also be of interest to Developed Countries Welfare Systems – e.g. the USA Food Stamps system (which is in 2010 very well used with a huge uptake) is a very primitive form of what I propose here. The UK and other countries are currently (2010) implementing austerity measures – it would be nice to know that welfare payments are not going to buy alcohol, tobacco and other drugs.

World Food Program (WFP) is already looking at getting cash, vouchers or e-money into areas of food stress and famine. Such a system would tie in wonderfully with what they are trying to achieve.

Plan International have a Child Sponsorship Project which could almost certainly reduce costs and increase its reach by using such a VBA system.

Global Giving, Kiva.org and other schemes could operate more efficiently and effectively.

Resource-rich Third World countries where almost the whole population is poor (there are many of these) could distribute resources to their populations on a 100% or on a targeted basis. Of course just giving money to the poor without thinking can create problems – for example there is probably an amount per day which can be given to a population without creating alcoholism, laziness and dependency. In fact giving resources for the right targeted usage can make a country develop.

Summarising, such a VBA system can:

- Operate commercially

- Enable remittances from family, in-country and internationally

- Enable highly targeted social payments from Government, family, Donors, NGO’s etc..

- Enable and facilitate highly targeted microfinance projects

What is preventing or has prevented such VBA’s from springing up already? Several factors are operating:

1. Most cashless transfer systems in the third world are fixated on using mobile phone and mobile phone ownership as the primary and only technology for effecting such transfers

2. Most cashless transfer systems are also fixated on high costs per transaction – typically US$ 0.30. With such a cost, mass uptake is dubious except for in-country and international remittances, where alternative costs are also high

3. Governments, Donors and NGOs lack imagination, innovation and especially the political will to conduct genuine programs which will uplift the people of the third world

Alex Weir, 21 June 2010, Harare

Universal Virtual Bank Account

Detailed Workings

1. Where possible, smart phone or PC are used. As a less desirable alternative, SMS (text messages) are used, in conjunction with an SMS gateway.

2. An https (SSL) option is the preferred route. In practice with low bandwidth then all https screens and menus will also be offered as http screens.

3. Operations covered in this document include:

a. Starting an account

b. Making a payment

c. Putting cash or bank funds into an account

d. Getting cash or bank funds out of an account

e. Getting issued new TAN numbers

f. Reclaiming VBA value if all TAN numbers are lost, stolen or misplaced

g. Explanation of the 3 distinct account numbers

h. Making a remittance in-country

i. Making an international remittance

j. General Notes

4. Starting an account:

a. Ideally, a national ID card number is entered and submitted. The system returns:

i. Account number for making payments

ii. Account number for receiving payments

iii. Account number for querying balance

iv. A set of TAN numbers for making payments and for doing other maintenance activities (transaction authorisation numbers – effectively one-off PIN numbers – much more secure than using a single PIN number, even if that PIN number is sometimes changed by the VBA account holder)

b. Alternatively, no national ID card number is entered. The system returns the same as above.

5. An account tied to a national ID number (or equivalent) which has also been verified (this can often be done by an approved/authorised merchant during a routine transaction) becomes eligible to receive social payments. In fact, they may receive social payments while still unverified, but will not be able to spend or convert those social payment monies until they are verified (and those monies can be reclaimed by the agency which issues those social payments)

6. Similarly, anyone who started an account without submitting a NICN (National ID Card Number) will be able to attach their NICN later and also of course have that verified.

7. It may be possible to have several VBA’s attached to the same NICN, but only one of these (by default the latest) will be eligible for social payments. That covers a situation where a person loses or has stolen VBA details but has so little balance in those VBA’s that he or she would rather simply open a new VBA.

8. An anonymous VBA (no NICN and no verification) will be subject to account limits as per most international KYC (know your customer) rules. This affects maximum balance and also maximum amount per transaction. Those international rules may also be modified with time to affect maximum money flow per month.

9. Making a Payment. Again this can be done using smart phone or PC, with or without https/SSL. Supermarkets, shops and even roadside vendors/street vendors will use mainly this method. The capital investment for a basic smart phone is US$ 64-00 or less retail (Nokia 2323 or equivalent).

10. A screen is brought up on the web browser. This has the fields:

a. Payee account – this is entered automatically by the system using a cookie on the smart phone or PC – this is the account of the vendor, shop or supermarket

b. Amount to be paid – this is entered by the vendor

c. Currency selection (optional – disabled for most countries)

d. Payer account – entered by the vendor on reading or listening to the purchaser. Alternatively can be entered by the purchaser

e. TAN number - any one of the currently available TAN numbers in use by the purchaser. Entered by the vendor on reading or listening to the purchaser. Alternatively can be entered by the purchaser

f. Any restrictions on use of the monies – e.g. Food only, agricultural inputs only, education, medical, rent, utilities, etc etc.. This field would very often not be used, only being relevant to social payments and possibly remittances. In fact there would probably be a separate screen which is used when such restrictions are to be applied, to avoid confusing people when making routine payments to vendors and merchants.

11. When all these fields are entered then the SUBMIT button is pressed. The system communicates with the server through a conventional GPRS internet connection. The response gives an OK or a transaction refused message – if the latter then a reason is given. The system also can give a balance remaining for both the payer and the payee (that can be disabled or enabled by payer and by payee on their settings menus).

12. The process with SMS is similar – the same fields are entered, but are separated by * asterisk marks.

13. Putting money into your VBA

14. There are simplified and more complex models

15. In the simplified model, the system works with one partner bank in the operating country. The whole VBA system operates from 2 accounts with that partner bank – one holds the complete current balance as a sum of all the VBA accounts (no account is ever allowed to go into negative amount), and the other account holds the fees which are levied by the VBA system on the VBA users (typically US$ 0.03 per transaction). Cash or cheque is paid into or transferred into the main working account, and in the comments field is entered the destination account number following by an * and then following by an email address or mobile phone number in the event that the account number is wrongly entered. Note that usually the partner bank will have a simple online or offline screen which enables them to verify whether the account number exists.

16. In the best case, the partner bank has automated interfaces (almost certainly web services) which enable any and every deposit to be immediately reflected and immediately available in the VBA account. In practice, the transfer from the partner bank to the VBA account may be a batch process which occurs overnight, and which might well be a combination of manual and automatic actions.

17. More complex models will allow transferring money in through credit or debit card payment

18. That may well utilise a service or services like PayPal.com or MoneyBookers.com

19. Since international services sometimes take several days for the funds to actually move, one may have a situation where funds received internationally may be usable within the VBA system immediately, but may not be cashed in or even transferred to the linked partner bank account for those several days. But the money will be safe and will be guaranteed by the VBA System.

20. Alternatively, in-country vendors, shops, supermarkets etc (merchants) may if they choose take cash over the counter and credit your VBA account from their own VBA account. i.e. a cash-in service which is the reverse of a cash-back service offered by many shops. But they may levy a percentage or a fee of their own choosing for doing so. Or they may choose to do that free of charge to attract potential customers to their store. Typical fees may be in the region of US$ 0.30 or maybe 1-3% of cash value.

21. Getting Money out of your VBA

22. Note that in this connection, many 3^rd world countries (and we are considering primarily those countries as suitable operating theatres for this system) can receive international funds but cannot easily remit international funds from their relatively weak currency zone back to a strong currency zone (however maybe since the 2008 financial crash these terms should be changed!).

23. The main methods of getting money out of your VBA will be:

a. Making payments for goods and services, gifts or loans to family and friends

b. Using the cash-back facility (if available and if economic) with merchants in your area

c. Having your own conventional account with the VBA System Partner Bank

d. Having your own conventional account with another in-country bank with which the VBA system has an automated or semi-automated payment mechanism

24. If you are using options (c) or (d) above, then ideally (as above), there is an automatic online or quasi-online interface between the partner bank(s) and the VBA system. Alternatively, there is a batch operation which is possibly automated or maybe only semi-automatic which takes place once per day and makes payments from the VBA System Master Account into the linked conventional accounts in the VBA System Partner Bank. This kind of thing is just like monthly payroll operations which banks process using a structured standard format flat file. There should probably be checks and safeguards built in – at the least the VBA System extracts a statement of all the payments which have just taken place and compares the amounts and account numbers with the file submitted, sounding alarm bell if there are discrepancies.

25. Then having transferred monies from your VBA to your linked conventional bank account, you can withdraw cash in the normal way.

26. It should also be possible to collaborate with the Partner Bank so that cash can be issued from the ATM’s belonging to the Partner Bank, even if the VBA account holder does not have an account with that partner bank. The mechanism for doing that would be a 12-digit or longer issue code, valid say for 24 hours only (or less), which would be issued as part of the VBA System Menu (and of course using one of the TAN numbers).

27. Getting more TAN Numbers

28. The VBA account holder gets several TAN numbers when opening the account. Since each TAN number can only ever be used once, then renewal of TAN numbers is a rolling process throughout the life of the account. There is a special webpage for doing this, and the issue of more TAN numbers itself requires the use or sacrifice of one of the existing TAN numbers.

29. If the VBA account holder tries to use their last remaining TAN number for a normal transaction, the screen also has a tick box asking do you want to do the transaction and also issue the next range of TAN numbers at the same time. If that box is not ticked then the system puts through the transaction and also issues additional TAN numbers at the same time. There is also a screen which enables you to cancel all existing TAN numbers and at the same time to issue new ones.

30. Probably the system will issue 5-10 TAN numbers at one time. For SMS interface there will be a limit on the number containable in one sms message (184 characters). The number of TAN’s issued will also be adjustable from the maintenance menus.

31. Reclaiming VBA value if all TAN numbers are lost, stolen or misplaced.

32. If the VBA is linked to a NICN then the NIC can be used to reclaim the value. This is a manual function which will be done (we hope and assume) through the customer service department of the Partner Bank. There will be a charge for this service, which will be removed from the existing account balance before that lost balance is transferred to the VBA account holder’s new VBA. If the existing balance is less than the charge then the VBA account holder must hand over the remaining charge before the lost funds can be redeemed. If they don’t have that then the lost funds remain lost until they can find that amount. The charge will typically be US$ 1-5, probably depending on cost of skilled clerical labour in the country concerned, and also to discourage careless behaviour.

33. As an alternative to linking the VBA to a NICN, it may be linked to a mobile phone number (i.e. SIM Card). The same chargeable process can be applied. i.e. if a phone is stolen then the thief can reclaim account money. Because of the fact that a personal appearance at the partner bank is required then hopefully phone thieves will be discouraged. Persons who have their VBA linked to a mobile phone can use a TAN to report that problem to the VBA System. Their best process is to open another VBA immediately and immediately to transfer all their monies from the jeopardised VBA to the new VBA.

34. Explanation of the 3 distinct account numbers

35. Conventionally, bank accounts have one single number, which is used for making payments and also for receiving money, and thirdly for querying balance.

36. A higher level of security is obtainable if a bank issues at least 2 and possibly 3 separate account numbers, with no apparent relation to each other (e.g. not sequential),

a. one of which (the highest level of security) enables payments to be made from that account to other accounts

b. the second number (the lowest level of security) enables payments only to be received from other accounts

c. the third number (intermediate level of security) enables current balance to be queried. A VBA account holder can give this number to a friend or colleague who is travelling to an area with GPRS coverage and/or the presence of mobile phones or smart phones and the friend can interrogate the VBA for balance and report back to the account holder.

d. This logic could be extended to conventional bank accounts, if only conventional banks were staffed with people of sufficient intelligence

37. Making a remittance in-country

a. Both parties open their own VBA and the recipient communicates their VBA ‘receive’ account number to the sender; alternatively only the recipient opens his own VBA and then communicates their VBA ‘receive’ account number to the sender.

b. The sender does a cash-in transaction direct to the recipient’s account or he does a cash-in to his own account and then a transfer from his own account to the recipient’s account. He can use a cybercafé or a smart phone. The cash-in can be at a supermarket or other merchant, or it can be through the partner bank; both these procedures are described above in the document.

c. The recipient uses his VBA to buy goods and services with merchants who also have their own VBA account. If the sender has flagged their remittance as being only for food, agricultural inputs etc etc then the recipient is limited to those category(s) when spending the funds with merchants

d. The merchant may use his VBA funds to buy from wholesalers or may convert them into a ‘real’ bank account with the Partner Bank. If the ATM option is in operation the merchant can convert his VBA funds direct into ATM cash (described above)

38. Making an international remittance

a. There are several possibilities

b. The sender has his own VBA in-country (easy to open from anywhere globally), the sender also has a ‘real’ account with the partner bank and has enabled electronic banking with that partner bank. The recipient has their own VBA and has communicated that account number to the sender. The sender does an international bank transfer to his own ‘real’ bank account. The sender then does a transfer from his own real bank account to the VBA System Master Account, with his own VBA account number in the comments field. The sender then does a transfer from his own VBA account to the recipient’s VBA account. The stages after that are as per above in (37c and 37d)

c. Similar to (38b) above, but the sender does not need his own VBA account – the transfer from his real account with the Partner Bank can be direct into the recipient’s VBA bank account. This however makes the business of applying restrictions as to the spending of the received monies more complex, since there must be structured codes in the bank’s payments comments field.

d. The sender has a PayPal.com or MoneyBookers.com account and the VBA System has put in place a mechanism to receive such funds. The sender can then transfer direct into the recipients VBA or into his own VBA and then from his VBA to the recipient’s VBA. This use of PayPal.com or MoneyBookers.com is very much but not solely a way to ease and make more secure the use of credit or debit card payments.

e. The VBA System has an interface with Western Union and/or MoneyGram.com where cash can be input at the donor country end.

f. The VBA System has a bank account with one or several international or western-country banks. Funds can be put into this master account with structured comment indicating the destination VBA account (and country!).

g. Variations on any or all of the above.

39. General Notes.

40. Note that in general terms, it is possible to set up a VBA system with basic functionality, with either a stated or any unstated intention to expand that functionality as uptake, revenue and profit appear. Note also that generally speaking, functionality which relies on collaboration with others often takes longer and becomes more expensive than anticipated.

Cashless Transfer System – high level requirements before setting up such a system

Alex Weir, 25 June 2010

1. A collaborating Bank (Partner Bank) is absolutely necessary in all the scenarios outlined in this and in related documents.

a. This Partner Bank ideally has Web Services available for making instant payments to other accounts in the Partner Bank from the VBA System Master Account. But being realistic, very few banks globally (?) have that kind of advanced but important facility.

b. At a minimum we require the capability to submit once per day a payment list which is very much like a payroll list – destination account number, amount transferred, and probably a comments column (which may state ‘from xxx VBA System – your residual balance in VBA account is US$ xxx.xx’)

c. The Partner Bank must also have the facility for the VBA System Master User to request an electronic online statement. This will be used once per day to semi-automatically process inpayments into the VBA system (both local and international)

a. The VBA System should also communicate with PayPal.com, Moneybookers.com or whoever else is used as the credit card handling method. Such stuff could in theory wait until Phase II of the operation, but moves should be made early on to firm up exactly how that interface would work. Once again one may have to accept that it will be a semi-automatic interface.

b. The VBA system should probably also include an interface to Western Union or Moneygram (if they are willing to collaborate!), for receiving international monies into the VBA system. Alternatively, the VBA system should operate also in the main remitting countries.... but maybe for receiving and sending only.... It could accept monies via PayPal.com

3. Ideally, the VBA system is launched to coincide with a donor or NGO project to distribute goods, services or e-payment to a reasonably large number of people (e.g. an agricultural inputs project or a food distribution project). That way there is automatically a good user base. Alternatively, the VBA system is launched initially as a remittance system (as per MPesa in Kenya). The amount of publicity required to reach a credible volume of business should not be underestimated.

a. A FAQ (frequently asked questions) web page or set of FAQ web pages. This will be the main tool of the call centre in answering queries. There should also be a downloadable and printable PDF file which contains the complete FAQ system. That should be available to be consulted at the Partner Bank. Paper copies can also be available for purchase at the partner bank.

b. A web database system where end users can log their enquiry or complaint, without any guarantee that these queries will be answered or resolved. There will be management statistics on this web database system, which will tie into the call centre system.

c. A call centre operation to answer queries on the system. This should use premium rate number so that the cost of the call centre is met by the cost of the call. The call centre will use the FAQ web pages (online or locally stored), and will have a simple online call logging web database system for the call centre personnel to use.

5. An SMS Gateway will be of advantage to include vendors outside the smart phone system and also normal person-to-person transfers. But being realistic, the only way that an sms system can coexist with a US$ 0.03 per transaction system is if the sms gateway is free of charge. The only people who can do that are the MNP’s (mobile network providers), and they are unlikely to be so charitable. The rapid encroachment of affordable smart phones may render sms access unnecessary. Certainly to include an sms gateway will probably mean a lot of persuading or a lot of lobbying. Probably a lot depends on mobile phone penetration rates and the penetration rate of smart phones (which are rarely used anyway for internet access). The charging structure for internet access also has a bearing – i.e. is it per Megabyte or is it a flat fee per month, or a mixture of both; and are internet costs reasonable or too expensive?

6. Moves to wholesale or retail suitable smart phones may assist the project – even working with and/or educating and persuading retailers and/or wholesalers may be sufficient.

7. Working to persuade the MNP to offer easier and/or less expensive data access may be important.

8. Summary – for a basic rollout, we need the following:

a. (1b) and (1c)

b. (2) we can probably skip at the start. As long as international remittances can be done through bank transfer to the partner bank

c. (3) would be a very big plus

d. (4a) is required, the others are optional/luxuries (?)

e. (5) can be dispensed with, unless we have a charitable MNP and/or a pro-people Government

f. (6) may be important

g. (7) may be important

Alex Weir, 25 June 2010

Cashless Transfer Systems – a Simplified Model for In-country transfers

By Alex Weir, 29^th June 2010, Harare

1. The system uses an Agent for the cash-in process, and another agent for the cash-out process

2. The person arrives at the cash-in agent (who also of course does cash-out transactions), specifies the amount he wishes the recipient to receive.

3. The cash-in agent enters that amount into his smart phone, his own agent ID number, and his own PIN number. The sender then enters also a one-off PIN number of this own choice (which will be at least 4 digits and maybe 6 digits). The entry of both PIN numbers is done on the smart phone screen displaying **** characters, so that the sender cannot see the agent’s PIN and the agent cannot see the sender’s one-off PIN.

4. By the way, the agent’s ID does not actually have to be visible on that screen – it can be entered through another maintenance screen and stored on the smart phone as a cookie – that will also decrease probability of sending agent impersonation. In such a case the use of a sender’s PIN may no longer be necessary.

5. And the agent’s ID as sent on the screen will not be the same number as the agent’s ID as displayed on their kiosk – that is a security feature of the System. The 2 numbers will be linked in the System, but nowhere else.

6. The system – if the sending agent has sufficient credit with the system – responds with a 12 digit one-time issue code, and also indicates how much the sender must pay the sending agent, and how much the sending agent must remit in due course to the Remittance System. Typical values for sending US$ 20-00 might be a sender payment of US$ 21-00, a sending agent fee of US$ 0.40, and a due sending agent payment of US$ 20-60.

7. The system also gives the agent his current balance in both his transaction and his fee accounts. Transaction balance may be zero, positive or negative depending on mix of cash-ins and cash-outs. Fee balance may be zero or positive, depending on number of transactions processed since last reconciliation.

8. The sender copies down the 12 digit OTIC using pen and paper (better without leaving an impression on a pad underneath – i.e. write on a hard surface with no underlay).

9. The sender now contacts the recipient (by voice phone, sms, letter, email or any valid technique), and passes on the one-off PIN number and the one-time issue code. The sender also indicates the amount being transferred. Note that senders and recipients who want to be highly secure can pre-arrange the OOP beforehand, and therefore there is no electronic message or voice call which contains both OOP and OTIC. A different OOP should of course be used every time for high security.

10. The recipient goes to any local agent, checks does the agent have the required amount as balance, and if yes then gives the OOP and the OTIC to the agent. The agent enters those 2 numbers into his smart phone with his agent ID and agent PIN number, and then the system gives an OK and indicates pay out 20 dollars and take 40 cents processing fee. The system also gives the agent his current balance in both his transaction and his fee accounts. Transaction balance may be zero, positive or negative depending on mix of cash-ins and cash-outs. Fee balance may be zero or positive, depending on number of transactions processed since last reconciliation.

11. The OOP system is used so that the issuing agent cannot cheat the sender, by reading his OTIC and using that himself or through a colleague to try to impersonate the recipient before the real recipient presents himself to an agent.

12. If for any agent the cash-ins and cash-outs balance each other or are within a reasonable amount for a cash float (say US$ 100 – 500), then there is no need for daily or more frequent reconciliation through bank transfers. Also of course, minimising bank transfers is desirable since they usually cost money. The agent makes money by handling maybe 50 transfers of 20 dollars at a fee of 40 cents each, making 20 dollars through fees, and it costing him maybe 30 cents in bank fees for the in-payment or out-payment and maybe another 30 cents in bank fees to replenish his cash float.

13. Note that the smart phone system can be backed up also by automatic emails from the system to the agents’ email accounts (if any). And when the agent’s credit is close to its limit the system will remind on the screen and by email that an in-payment from the agent to the system is due. Out-payments from the system will usually specify either a minimum amount and/or a maximum timeframe – e.g. if an agent has done only 3 transactions of 20 dollars and then no more business for 3 working days then the system will pay out, even although the 60 dollars is below the normal lower out-payment limit of 100 dollars.

14. When an agent makes an in-payment to the system he quotes his agent number in the comment field of the pay-in slip. Similarly if he makes a bank transfer (manual or electronic). The system can automatically or semi-automatically process those statement lines of in-payments. As soon as an in-payment is received by the system an automatic email is sent out and the statement balance is immediately adjusted.

15. Out-payments from the system are done using a payroll-type flat computer file which is automatically or semi-automatically generated by the System and is submitted to the partner bank. Ideally this occurs only once per day overnight but realistically some agents doing rapid business will request replenishment twice or more per day.

16. All agents are required to open an account with the partner bank for simplicity and speed, and to keep charges down to low levels. These accounts with the partner bank can be savings-type accounts – i.e. no negative balance allowed, and no cheque book issued.

17. Agent transactions are paid at typically 40 cents, and the system takes typically 10 cents per transaction (20 cents for cash-in plus cash-out). The system operates on a parameter basis, and therefore all charges can be dynamically modified from a management console without reprogramming. Also different agents can be paid different amounts, although the charges to the sender should be the same for all (?).

18. There could be some problem that recipients are short-changed by the agent – i.e. instead of handing over the correct 20 dollars, some agents may try to give only $19-50. There must be a reporting channel for such misdemeanours, although if an agent is the only one in an area, the system operators may have no options available (except to seek out additional agent(s) for that area). Similarly, some sending agents may try to charge more than the stipulated 21 dollars.....

19. The agent may have a sign or blackboard outside his kiosk or shop indicating whether they are open for cash-in’s and/or cash-outs, to save time and frustration on the part of senders or recipients.

20. As a refinement, when giving the OTIC to the sender, it may also give a complaint code in event of any problem experienced by the recipient. That complaint code should be sent to the system (electronically probably) along with the displayed agent code of the attempted cash issue, and of course the contact info (probably mobile phone number) of the complaining party(s). Similarly, the cash-out operation should give a complaint code to the recipient.

21. Actual commissions charged can be based on published charges by systems such as MPesa (Kenya/Safaricom) and other internal and international money transfer agencies. They can also be positioned to compete with existing internal remittance systems, e.g. run by postal services/ post offices.

22. Agent investment involves possessing a smart phone (Nokia 2323, C1-02, C1-01, or C2-00 at US$ 55 or less retail), plus data charges (can be as much as US$ 0.25 per megabyte for casual usage or US$ 25 per month for pre-paid data contract, plus the costs of running a cash float of maybe US$ 100-1000, plus bank charges for inpayments, making and receiving bank transfers, and issue of cash.

23. When the sender has a conventional bank account or VBA (virtual bank account or virtual wallet), there should also be a process of him getting directly the OTIC or combined OOP+OTIC without recourse to an agent. This can even extend to the bulk payment of payroll or up-country workers with no bank accounts – a simple xml or excel file of amounts is submitted to the system and the system responds with a corresponding list of OOP+OTIC numbers for cash issue....

24. Although we talk about smart phone here, of course conventional PC with internet connection and browser is also perfectly capable of doing all the operations discussed above.

25. Apologies to all readers for being lazy in this document and consistently using male gender – this is not intended to exclude women from this business or to make any judgement on male vs female suitability as business persons.

By Alex Weir, 29^th June 2010, Harare

Cashless Transfer System – discussion of new features before design and creation of integrated system document

Alex Weir, Harare, 5 July 2010

1. Clarification of operation of Agents for In-country money transfers:

2. These agents will operate by having their own VBA. Their VBA will be different from normal VBA’s in that they will be allowed negative balance up to their credit limit. Each agent can have their own credit limit within the general guidelines.

3. In addition, there may be 2 categories of agents – Normal Agents and Super Agents or Master Agents – the Super Agents will have higher credit limits and may be able to take cash from normal agents and thereby enable those normal agents to do more business for the VBA System, by re-zeroing their credit balance (with their credit amount effectively transferred to the Super Agent).

4. For bill and utility payments, the utility companies will receive monies via their VBA. Their VBA will of course not be subject to KYC (know your customer) limits. They will receive their monies through the partner bank(s) by routine daily or other payroll-type payment list file. There must be available enough fields (e.g. account number, invoice number etc) and also reporting for utilities – maybe even special HTML report pages on the website which utilities can view and download. Encrypted files might be required, or attachments which are auto-emailed or manually emailed as a weekly task for the management controller. The data will probably be supplied also as XML files which can be easily converted and imported into the utility’s existing database.

5. Utility VBA accounts must be disabled for paying/spending – they must be in-payment-only accounts, with bank transfer to one designated account only.

6. Note that the VBA system should be designed to cope with multiple partner banks! **

7. Airtime payments discussion:

8. Ideally, an agent OR a VBA account holder can top up a mobile phone by entering the target phone number and the amount and the paying account number (with PIN or TAN as appropriate) and the MNP network in a special web page (at one time the target phone number would specify the network but number portability has superceded that former situation). The required data is then transmitted to the MNP, who do the actual topup and send the appropriate sms to the topped up phone. The MNP also respond to the VBA system who in turn respond to the agent. The MNP’s own VBA account is incremented and the VBA system takes a fee and decrements the agents VBA account (if enough credit exists). Thus the VBA system acts as a clearing house for many VBA agents and even VBA account holders in their dealing with the MNP. When a VBA account holder themselves do the topup there is no agent fee – either the VBA system take a larger fee or the saving is passed on to the VBA account holder – who gets a discount; this may depend on/vary by MNP, who obviously do not want to irritate their conventional vendors and even their VBA Agent vendors.

9. In reality, the above scenario as per (7) requires some developed web services etc and online facilities which may not be realisable until the VBA system has volume and credibility. Therefore a simplified model must also exist, whereby the (usually 12 digit) airtime activation code (AAC) and voucher value are stored by the VBA System and is issued to the agent or VBA account holder as required. The phone user then enters that code as if it comes from a scratch card in order to top up his airtime. This scenario involves that the MNP’s sell a series of AAC’s to the VBA System for a discounted amount. The only problem with this scenario is that it opens the VBA system to internal fraud – if someone (typically System Administrator or Database Administrator) can get access to read the codes they can sell those codes privately before they are sold by the VBA system and input by the user. Thus encrypted storage of those codes should be used.

10. The restriction by category for social payments should be quite simple. It involves merchants having one or several accounts which are flagged as being a particular category – e.g. school fees, pharmacy, food store, agricultural inputs stockist, textbooks, medical fees, building materials, etc etc.. Such a registration process should involve the merchant signing some legal document and assenting to certain terms and conditions – the main one of which is not to enable or assist the purchaser to evade the intention of the system by diverting monies meant for one purpose into another purpose. ** think about restricting monies to be used for certain merchants and/or categories *** (Al’s comment)

11. The only minor (system) complication will be to enable monies to be allocated across several categories; and also that the system must be able to add new categories as a function from the management control panel. Merchants and possibly normal users must be able also to suggest categories which should be added. The entry and storage of some funds across more than one category will involve possibly marking that fund allocation as for example FAS meaning food, agricultural inputs or school fees. If someone has funds marked FAS then they can be used to pay part or all of any payment for food, agricultural inputs or school fees; if the bill is greater than the funds marked F or A or S or FAS etc then funds from the users general/open account can be used to complete the payment.

12. Interest payments – interest can be paid daily or at the time of each transaction. Interest payments may typically be in the order of fractions of a cent. Interest may be based on minimum balance over a time period, or they may be strictly arithmetical – it depends on the interest situation regarding the VBA Master Account in the Partner Bank. Therefore a number of scenarios will have to be programmed for, with a parameter deciding what method will be used. Of course it is perfectly possible that no interest will be paid from VBA accounts.

13. Multi-Currency. As an extreme case (e.g. Zimbabwe) it may be necessary to allow deposits and payments in multiple currencies (e.g. US$ and ZAR – South African Rand, Pula (BWP), ZWD (Zimbabwe Dollar), GBP, EUR etc). That can get very complex, and will probably not be programmed in any first release (and possibly never). An alternative scenario may be that funds which originate from a hard currency can be held in that or another hard currency until they are required – that situation may be desirable in a situation where inflation in the local currency is rapid. Think about the VBA system having both dollar and local currency account with the partner bank....**

14. ATM/OTC issue code. (OTC means over –the-counter). One situation which can arise in the system is the need for someone without any conventional ‘real’ bank account to get cash from the Partner Bank or from an ATM Cash Machine. It would be nice if the VBA system can access ATM’s directly using VBA account number and PIN or TAN number. That should be in future planning. It would also be nice if the VBA system can issue a one-time-issue-code (OTIC), which will be a code which one or more families of ATM machines can understand and respond to by issuing the necessary cash. Of course this OTIC will be tied to a certain amount of money – if that amount is not available then the transaction will simply be refused. This again is a future project, but the system should be planned and designed with that in mind.

15. International Transfer. The main problems with international transfer are:

a. Uncertainty regarding the forex rate which will apply. This can be countered or partially countered by releasing 95% of the funds through the VBA system until the actual landed amount is known.

b. The long time (several days typically) for conventional banks to effect a transfer. This can be countered by crediting the destination account with monies which are marked as say 4-day-redeemable – i.e. can be used within the VBA system for payments etc but cannot be redeemed by anyone in the VBA system before a certain date – e.g. 4 days from payment. ** be careful – never release in any form monies which are not yet in your own account, in case a transaction fails **

c. Relatively high charges which can be levied for single payments or for a few payments – this can be countered by ensuring volume, having a VBA system bank account in the Sender Country, and bulking one forex operation to cover a large number of transactions.

16. There are several ways potentially to resolve some or all of these problems:

a. Use VISA, MasterCard, and/or American Express to pay an in-country vendor (e.g. the VBA operation may have a merchant account in the payment destination country). The payment will be in destination country currency. That can possibly reduce but not eliminate the 3 problems above.

b. A conventional international bank transfer into the VBA Master Account with the Partner Bank, with the destination VBA account number in the comment field. Alternatively, the email address of the sender or receiver in the comment field. If the VBA Number is quoted then the funds will be added to that VBA account. If no VBA number is quoted but an email address is quoted then an OTIC will be emailed to that email address. It will then be the responsibility of the email user to inform the recipient as to the OTIC number. Since emails are an open and insecure method, this should be augmented by an OOP + OTIC system (one-off-PIN number) as discussed in a separate document of this family. The revised and improved process is described immediately below:

c. The sender goes to the website, supplies an OOP, his or the recipient’s email address, and the approximate amount and country to be transferred. He gets an intermediate identification number, which he includes in the bank transfer comments field. (IIN=12365461253). He makes the bank transfer to the VBA master account with the comments field as above. The system creates an OTIC and emails (or sms’s) that to the email address supplied along with the amount in local currency which will be paid out (net of forex charges and VBA and agent fees). The OOP + OTIC when taken to an agent will ensure the monies are handed over. ** Al does not like this IIN – maybe we call it a transaction number? ***

d. Variations of this scenario are that the VBA system has a bank account in the sender’s country, and allows and encourages the sender to have a VBA account which stores and indicates the balance in the sender’s currency (as an alternative the balance could be held in the recipient’s currency). The sender can then make one transfer into the VBA system which can be used for multiple or many transfers to the recipient. This means that there will be very small or zero time delays on transfers, but that the sender has to have some cash float in his VBA account.

e. Variations again use PayPal.com, MoneyBookers.com or some similar system to effect the transfer to the VBA operation.

f. Work in collaboration with Western Union, MoneyGram or similar – this may be unlikely since they would want to run the operation themselves....But there may be ways to utilise such services without them really knowing what is going on (for some time only?).

17. Statements – generally – statements should be available on the web. Account history may also be required by law enforcement agencies (national or international), as would be the requirement to store history for a time period. This would probably involve a separation of data required for account operation (which would be live in the database) and the rest of the history, which could be written to textfile (.txt, htm or another)

18. Microfinance

19. Microfinance can be done in 3 ways:

a. The VBA system has inbuilt microfinance management capability where any VBA account can act as the disburser of loans and the recipient of repayments. Using that facility a number of operators can run their microfinance systems, each with their own interest rates, repayment periods and other admin charges. The VBA system provides management statistics and reporting for the MFO (micro finance operator), either free of charge or for a fee. The system will also of course generate MFI customer quality and credit suitability reports – ideally tied to National ID Number.

b. The VBA system can be used by any MFI (micro finance institution) simply to handle loan issue and repayments. All calculations and reporting will be done by the MFI’s own system. The MFI system should possibly have a bulk payments facility whereby a file can be uploaded (and verified by a single PIN/TAN number) to execute a number of payments from one VBA account to a number of VBA accounts. The MFI system can benefit greatly from the capability of the VBA system to restrict the use of monies to one or several categories.

c. The VBA system can be used by the VBA account holder to make a series of extended payments – instead of paying 90 dollars he may commit to paying 1 dollar per day for 100 days ahead. This may be particularly useful for retailers if the VBA account holder has incoming social payments. E.g. for a sewing machine or plough. Any merchant wanting to make such a deal may have the right automatically to view any and all existing similar credit arrangements (and all incoming social payments with their status – time period limited or indefinite)

20. Communications – incoming messages for persons who are not mobile phone owners. There may be a 4^th account number issued – which is the number to be used for sending messages to the VBA account holder. Messages can be sent from one of the VBA system screens, or can be sent by SMS to a System Number (if SMS is included in the system). Such an sms may have a structure – e.g. ‘MSG*263912590516*please call me asap +441622764712 sister Louise’. The VBA system will have a special screen for sending messages and also a special screen for checking for and for receiving messages. PIN or TAN may also be used/required for sending or reading messages – flexibility should be allowed. If a VBA account holder has an incoming unread message and does another transaction (e.g. pay/buy, check balance, check statement etc) then they will be informed that they have a message or the message will even be displayed on the screen, depending on setup parameters and system operation. Someone sending a message can even have it classified as open, private or top secret as a means to control possible display of incoming message in front of others. Also as routine, important or urgent.

21. Incentives for Agents to recruit VBA account holders – any new VBA account holder who quotes an agent’s VBA number when opening his or her own VBA account will result in the opening agent getting a percentage of all fees on the VBA account holder for a certain timeframe (e.g. 3 years?). This will also apply to ordinary VBA account holders as well as agents. That way you encourage a pyramid-type incentive scheme whereby the number of VBA accounts reaches saturation (?) in a very short period. This kind of system also solves the problem of marketing, expansion and reaching an economic critical mass of account. In case the beneficiary account is lost or discontinued, the payments are NOT transferrable (since admin would become too complex). There will be a single level commission scheme only – no Multi Level Marketing (MLM) cascading commission payments system will be used. Note that as well as agents and individuals benefitting from this scheme, also charities, religious organisations etc can encourage people to use them as the referral account (like the Red Credit Card).

22. Receipt - Offer option of sms or email receipt instead of or in addition to paper printer receipt (if available). Sms receipt will involve immediate charge/deduction of a certain amount (typically 20 or 10 cents)

23. Escrow Payments. Offer a system whereby an escrow payment can be made – the payment is made as usual on the browser screen, but a box is ticked also which indicates the payment should be an escrow payment. The system effectively removes the amount from the sender but does not yet credit to the recipient’s account – it will show up in the recipient’s statement as a pending escrow in-payment. The after-submission screen for the payer shows a transaction number and gives a sender-authorisation code. The recipient can bring up the transaction by inputting the transaction number, and can view the amount and the sender. By the recipient or the sender inputting the sender-authorisation code then the payment is completed and is available to the recipient. Basically, the sender keeps that sender-authorisation code secret until he receives the goods or services in good condition. Then he rolls the transaction forwards to completion by inputting his sender-authorisation code. If he is not satisfied then the monies remain in limbo until the recipient enters their PIN or TAN number into an Escrow-Rollback Screen. If the recipient is not willing to do that, then the sender has to implement some legal process in order to produce some paperwork which is then presented to the VBA Operator, who conducts a manual operation from a special admin screen to rollback the payment. There is an admin charge for such an operation. The legal outcome of course may equally be that the escrow payment should be rolled forwards instead of being rolled backwards – the special screen will perform either operation. This escrow system may facilitate mail-order type of deals. Either party intending to conduct an escrow deal should be allowed to see stats on the escrow history (if any) of the other partner (in case the partner is a serial defaulter or serial troublemaker). There should of course be a special fee for an escrow deal, since it is of value to both parties. The fee may be related to the payment value or it may be a flat fee, or a combination of both... Another possible outcome is that a part of the monies is rolled forwards and the other part is rolled backwards. The Rollback/Roll forwards screen should allow such a partition to take place – the roll forwards amount can only be authorised by the sender and the roll backwards amount can only be authorised by the recipient.

24. As a (better) variation on the escrow system described above, let payment be pushed through on delivery (with or without physical inspection by the purchaser). The goods arrive with an agent, the purchaser or his nominee must supply the escrow TAN number to receive the goods. The TAN is input by the delivery agent and if OK the goods are handed over. There can be a 3- or 5- day automatic rollback if the goods are not delivered by that time.

25. Multi-Language – the system will be available with a wide variety of languages. Different users inside the target country may choose their own language for screens and multiple choice selections – e.g. Spanish or English in the case of Nicaragua, French or Flemish in the case of Belgium, French or English or Cameroun, etc etc.. Such features are already in place for the voice prompts in MNP automated systems.

26. VBA system can be used to run an auction or reverse auction. Any and all VBA account holders with balance can bid. The funds for each bid are locked until superceded by a higher bid, at which time they are released. In the reverse auction, the first bid wins. In the event of several bids coming in at about the same time, the losers receive an appropriate message and their funds are never locked or committed. Such an auction system can be combined with the escrow system until the goods are physically received. The auction can be conducted remotely or by persons at the auction site using their mobile devices.

27. Restaurants etc can advertise that they give a certain percentage to the poor, to homeless shelters, food kitchens etc.. The person paying by VBA account can have the payment automatically split by the VBA system – as they pay the restaurant they can see 98% of the tab going to the restaurant and the 2% to the charity.

28. The VBA system can do standing orders and also a kind of direct debit to other pre-identified VBA accounts (can be accounts of utility companies, relatives etc). It the standing order or direct debit does not have enough funds the VBA holder will be notified through the messaging system, and unless countermanded the transaction will go through next time funds arrive in the account. The direct debit is like a standing order but with a variable amount. Unlike conventional bank’s direct debits the variable amounts will have a ceiling per payment and a ceiling per calendar month which can both be set by the VBA account holder. Default values will be typically 50% greater than the average bill. If the ceiling is breached then the VBA account holder will be informed through the messaging system and the ceiling amount only will be paid.

29. The VBA system can be set up so that every transaction sends an email to the VBA holder (when appropriate). SMS alerts can also be set up, but they will be charged unless free SMS’s are available to the VBA Operator.

30. The VBA system can be used to assist in public share-buying exercises (e.g. IPO’s and privatisations). This will very possibly use the escrow facility or some variation of that. In the event that people are submitting applications for shares but not every application can guarantee to be met, then either applications will be granted on a time basis (first come) or on a random selection basis. The VBA system can have features which assist or fully effect these processes. Obviously a fee is paid by the issuing organisation.

31. The VBA system can be used as alternatives to medical insurance and unemployment insurance schemes. This applies mainly to monthly and/or weekly salaried employees. The employee’s and employer’s contributions can be put into the employee’s VBA account and restricted for medical fees or pharmaceutical supplies (or funeral expenses) only. It would be possible that the bulk of an employee’s funds like this accrue with minimal spending over 20 or 40 years before any major condition appears (if ever). On death these funds can be transferred to other family members or named beneficiaries, or can be converted to usage for funeral expenses.

32. Unemployment benefit could work similarly – the government can issue a statement that the ex-employee is now officially unemployed, enabling him to draw from his previously locked funds. There would be a fee for the manual processing by the VBA Operation.

33. Pension payments. Investments. Peer lending with interest.

34. A commercial credit system, similar to microfinance – which would then allow negative account balances (overdraft) to approved persons.

35. Youth clubs, overnight hostels, secure storage boxes, showers etc could be paid for from social payments.

36. Salesmen could go around selling stuff from brochures (paper or electronic) and taking escrow orders through the VBA system.

Hardware requirements for Cashless Transfer System

Alex Weir, 11 July 2010

1. For individual VBA account holders, any smart phone is fine – the Nokia 2323 at US$ 55 is perfectly adequate. New Nokia models such as C1-1 and C2 etc are even less expensive and equally functional. If the VBA Operator enables SMS interface then any phone which does SMS will be adequate – Vodafone 150 and 250 at $15 and $20 would do the trick

2. For merchants it will be desirable to print slips, but some may choose to operate with hand-written receipts and issue of numbers.

3. Printing from smart phones is extremely problematic – there are workarounds, but it seems that the present generation of smart phones will not crack that barrier. Despite the apparent availability of technical printing solutions for smart phones, it seems that economically, it is better to go for low-cost desktops or (better I feel) low cost netbooks. These netbooks often run linux operating system, they have printing built in as standard, and some even have integrated GPRS modem and a card-slot for a sim card. This solution seems to be good. Some reckon to have slow browsing, but with Third World data provision, I don’t think anyone will notice. Some redirect web browsing through their dedicated server (e.g. Datawind), like Opera Mini is handled. That should be acceptable so long as that dedicated server is running and the company is in business; alternatively one has to have a guaranteed instructions to redirect all traffic direct to the application website for future use. Those who sell their netbooks with integrated data bundle will be able to strike some kind of deal with the VBA Operator, who may become a wholesaler and maybe even a retailer of the netbooks.

4. Any other solution opens the VBA Operator up to complications, and diverts from core business.

5. The only alternative which I haven’t examined to the netbook is the PDA type of smartphone – maybe some of them can print and also handle GPRS.

6. The low-cost desktops mentioned above can use conventional dialup connection, or (better) a GPRS connection – an external GPRS modem into USB port is probably the best – there are stick types and cable types. Normally these also give a higher data speed than using a smart phone as a modem.

7. There is another suggested usage in taxis – for that the netbook with POS printer running from cigar socket would make a lot of sense.

8. The proposed taxi application gets complex – the idea that we can swipe a credit card to pay the VBA operator’s merchant VISA account and at the same time identify that it comes from XYZ taxi becomes too complex – there are other ways of handling that situation, the best of which I think is for the taxi passenger to have a VBA account. He can top that up at the airport from the VBA operator’s kiosk, and then use VBA money in the taxi – with the netbook and POS printer.

Alex Weir, 11 July 2010