Which topics would be most engaging in an m-payment workshop for developing countries?
Payments
Asked by Question Bot01/Mar/20131 answer
1 Answer
F
Faisal Khan
Answered 01/Mar/2013
I would echo what Dave Birch has cited. I have attended many such conferences and workshops. All seem to focus too much on the technology aspect of it, how the USSD will work, how the APIs are easy, or look how easy our entire process flow is. All this (in my opinion) is secondary. Technology and processes can change overnight (literally).
Some view points on your question:
I'm not trying to down your answer in any manner, I again stress that a lot of people put too much emphasis on agents and payments, whilst not having an inkling of the backend processes, especially those concerned with the financial regulator, that would be required to pass a very stringent audit before even going live.
I have said this again and again, put a few people in front of a whiteboard, give them enough coffee and cigarettes and a payment system will take shape in a few hours. Missing from this skeleton is the regulatory and settlement engine and how it interfaces with the bank, specifically its core-banking software.
Some view points on your question:
- What is inherently very important is how interoperable your system and solution is to the existing payment networks and banks.
- Under which regulatory framework can you launch such a mPayment solution.
- Who is your underlying sponsor (i.e. financial institutions)
- How are net-off funds settled amongst agents (where few solution providers even know what a net off settlement is on agent side).
- How can 4-6-8 eyes collusion fraud be avoided? (i.e. 2,3 or 4 people in the chain of payments colluding to commit fraud)
- How are backend sales/tax or VATs settled on multiple payments, and how is the accounting of such done?
- What is the core banking you use? If not, who maintains the main ledgers and agent ledgers (this is a very important point from a regulatory point of view).
- How interoperable is your system to the existing ID verification and/or payment switch.
- How is KYC done on mPayments?
- Does your solution or workshop even start to address the AML aspects, especially velocity of payments in a network.
- How are person of interests or agents of interests assigned? Especially for issues like forward booking or net-off booking of funds (this is especially true for countries where tax and/or taxation reporting is an issue).
I'm not trying to down your answer in any manner, I again stress that a lot of people put too much emphasis on agents and payments, whilst not having an inkling of the backend processes, especially those concerned with the financial regulator, that would be required to pass a very stringent audit before even going live.
I have said this again and again, put a few people in front of a whiteboard, give them enough coffee and cigarettes and a payment system will take shape in a few hours. Missing from this skeleton is the regulatory and settlement engine and how it interfaces with the bank, specifically its core-banking software.