Upload
roberto-grossi
View
221
Download
0
Embed Size (px)
Citation preview
8/9/2019 Remote Payments White Paper FINAL
1/56
MOBEYFORUM
MobileRemotePayments
GeneralGuidelinesforEcosystems
WhitePaper
June2010
8/9/2019 Remote Payments White Paper FINAL
2/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page1
June2010
Copyright2010MobeyForum
Allrightsreserved.Reproductionbyanymethodorunauthorised
circulationisstrictlyprohibited,andisaviolationofinternational
copyrightlaw.
8/9/2019 Remote Payments White Paper FINAL
3/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page2
MobeyForumRemotePaymentsTaskForce
Chair:JonathanBye RoyalBankofScotland
Cochairs:
JonatanEvaldBuus CellPointMobile
OlivierDenis SWIFT
EditorialPanel:
SameeZafar Edgar,Dunn&Company
LiisaKanniainen MobeyForum
Ville
Sointu
Tieto
JonathanBye RoyalBankofScotland
JonatanEvaldBuus CellPointMobile
OlivierDenis SWIFT
Contributors:
BentBensen DnBNOR
OlivierCognet Nokia
EdnaCubillos RedebanMulticolor
ValentinEcheverry RedebanMulticolor
ViktoriaErngard Telenor
AlistairGates Edgar,Dunn&Company
GunillaGarpas Nordea
RiekusHatzmann AtosOrigin
PekkaLaaksonen Nordea
AnneLeneHvalen BBS
OlliJussila TeliaSonera
ThomasMagin DeutscheBank
JeanLucPellegrinelli CaissedEpargne
JackRobinson VocaLink
GerhardRomen Nokia
Minhvan
Le
Atos
Origin
BernardvanderLande AtosOrigin
OlliWelin TeliaSonera
MichaelWhyte SWIFT
Support:
TanjaViskari MobeyForum
IdaFloor MobeyForum
8/9/2019 Remote Payments White Paper FINAL
4/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page3
Contents
CHAIRMAN'SFOREWORD................................................................................................... 4
EXECUTIVESUMMARY........................................................................................................ 5
INTRODUCTION .................................................................................................................. 6
BACKGROUND&OBJECTIVES ............................................................................................. 8
MOBILEREMOTEPAYMENTS............................................................................................ 11
OPERATINGMODELS ........................................................................................................ 21
GAPANALYSIS .................................................................................................................. 28
COREPROCESSES.............................................................................................................. 30
APPENDIXCOMMONREQUIREMENTS........................................................................... 44
APPENDIXPROCESSFLOWCHARTS ................................................................................ 46
GLOSSARY ........................................................................................................................ 49
8/9/2019 Remote Payments White Paper FINAL
5/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page4
Chairman'sForeword
Whenagreeing
to
chair
the
Mobey
Forums
Remote
Payments
Task
Force
some
12
months
ago
it
seemedastraightforwardtasktoproduceaWhitePaperonmobileremotepayments.
Howeveritsoonbecameclearthatthisisahighlycomplexecosystemwithmultiplestakeholdersand
afastpaceoftechnologicaldevelopment.
Wequicklyhad to findaway toaddvalue to thedebateandutilisetheextensiveexperienceand
resourceavailablethroughtheMobeyForummembership.
OneofthegreatstrengthsofMobeyisthatitispossibletodrawonabroadbaseofknowledgefrom
the banking industry, payments processors and infrastructure providers, MNOs, handset
manufacturers,systems
integrators
and
consultancy
firms.
Thisuniquecombinationofmembersprovidesaperspectivenotavailabletomanyothergroupsthat
arefocusedaroundasingle industryor interest. Ofcourse itcanalsomakeconsensusfindingand
decisionmakingmorechallengingandalongthewaytoproducingthisreportwehadsomeheated
buthighlyproductivediscussions.
We also signed a cooperation agreement with the European Payments Council Mobile Channel
Working Group (EPC MCWG) which led to the sharing of early drafts andjoint discussions that
providedvaluablefeedback. IamgratefultoDagIngeFlatraaker,chairoftheMCWG,andtheteam
fortheirsupport.
Thereare
alarge
number
of
reports
on
mobile
payments
and
while
these
serve
avaluable
purpose
wewantedtodistinguishMobeyForumsoutput. Thisreportdoesnotdescribemobilepilotsand
implementations nor does it provide detailed technical implementation guidelines. Rather it
describes business models and core processes required to ensure interoperability and start the
market.
MobeyForumisaglobalorganisationhencethemodelsaregeneric,designedtobeadaptedtolocal
andregionalmarketconditions.
Payment providers and other stakeholders will need to determine which models best suit their
markets,whethertheyutilisecentralisedordecentralisedcommoninfrastructuresormodelsthatdo
awaywith
such
infrastructure
and
rely
entirely
on
direct
messaging
between
the
transacting
parties.
Finally Iwould like to thankTanjaViskariofMobey Forum forher supportand coordinationand
SameeZafarofEdgar,Dunn&Companyforhisinsightsandsterlingworkinpullingtogetherinputs
andeditingskills.
JonathanBye
RoyalBankofScotland&Chair,MobeyForumRemotePaymentsTaskForce
8/9/2019 Remote Payments White Paper FINAL
6/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page5
ExecutiveSummary
Withover
4billion1
mobile
devices
on
aglobal
basis,
the
mobile
phone
is
perhaps
the
most
successfulconsumerdeviceinhistoryintermsofconsumeraccess,penetration,andusage.
The mobile phoneoffers new possibilitiesand opportunities for offering awide rangeof
servicestoconsumersandbusinessesincludingmobilepayments.
The mobile phone can be used for makingphysical payments at a shop or some other
physicallocation orremotelywherepaymentscanbemadeirrespectiveofthelocationof
thepayerandthepayee.Thispaperdealswithremotepaymentsonly.
This paper suggests that the mobile phone number, and not any other specific code or
identifier,
should
be
used
to
identify
the
payer
and
payee
in
a
mobile
remote
payment
transaction.Usingthemobilephonenumberwillprovideuserconvenience,ensureprivacy
andthesecurityofpaymentinformation,andfacilitateinteroperabilityacrossstakeholders.
Formobileremotepaymentstoachievecriticalmassintheshortestpossibletimeframeand
to minimise infrastructure investments, it is essential to leverage existing payment
infrastructureasfaraspossible.Thepaper identifies guidelinesfordevelopingapayment
"ecosystem"stressing theneed for interoperabilityacrossdifferentpaymentsystemsand
stakeholdersacrosstheglobe.
This paper discusses three potential ecosystem models based on varying levels of
interoperability.These
are
summarised
below:
Common Infrastructure Model (CIM) suggests a central or distributed database
which links the mobile phone number with existing payment instruments such as
bankaccounts,paymentcards,orstoredvalueaccounts.Themobilephonenumber
isthenusedasthe"mobileidentifier"orMIDtoidentifythetransactingparties
Intermediate Operability Model includes the CIM model above and additional
capabilities to facilitatemobileremotepaymentsacrosssystems thatarecurrently
notinteroperable
Direct InteroperabilityModeldoesnotrequirecommon infrastructurebut indicatesthat the payment transaction format is modified and adapted to facilitate mobile
remotepayments.
This paper discusses these models, identifies the requirements for implementing the
models, and provides generic process flow diagrams for implementing secure and
interoperablemobileremotepayments.
1CIA World Factbook
8/9/2019 Remote Payments White Paper FINAL
7/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page6
Introduction
TheRemotePaymentsTaskForceof theMobeyForumhasdeveloped thisdocument for
industryguidanceandconsultation.
Mobey Forum is a global nonprofit organisation, driven by the finance industry. Mobey
Forum has over 50 members; the member categories are banks, vendors, payment
processors and MNOs. Its objective is to envision prosperous Mobile Financial Services
(MFS)ecosystems.
The mission of the Mobey Forum is to facilitate banks to offer mobile financial services
throughsharing insightfrompilots,crossindustrycollaboration,analysis,experimentsand
cooperation
and
communication
with
relevant
external
stakeholders.
The
main
focus
is
on
buildingsustainablebusinessmodelalternatives.
MobeyForumStrategyisthreefold:
Informational industry insight, firsthand experience sharing, knowledge
repositories,regularindustrynewsandmemberupdates
NetworkingMobeyWorkshopsconnect the leaderscross industries tobuildnew
relationships
Shaping the industry creating the future: interaction and ongoing liaisons with
standardisationorganisations,
analysts
and
industry
influencers
Mobey Forum organises four twoday Workshops per year, each specially designed to
address the most challenging current issues,facilitated by recognised leaders within the
industry. Workshops are highly interactive with opportunities for strategic learning,
networking and sharing of peer experiences. Additionally Mobey Forum fosters ongoing
Workgroups and Task Forces in order to promote the exchange of expertise, insight and
solutions.
MobeyForumwasfoundedinMay2000andnowitisanestablishedindustrybodyaiming
tocreate theMobileFinancialServicesecosystem.MobeyForumhasbecome the leading
sourceof
independent
cutting
edge
MFS
market
information.
Themobilephoneandtheservicesitoffershaveevolvedremarkablyoverthelastdecadeor
so.Initiallyusedmainlyforvoicecommunication,itisnowbeingextensivelyrelieduponfor
all types of communication messaging involving text and data exchange such as Short
MessagingSystem(SMS),MultimediaMessagingService(MMS)andinternetbrowsing.Both
voice and data communications are indispensible for consumers and generate billions of
dollarsforprovidersacrosstheglobe.Mobilephonesvastlyoutnumberpersonalcomputers,
televisions,ormusicplayers.
Another
major
triumph
of
the
mobile
phone
is
that
it
appeals
to
consumers
across
geographiestranscendingcustomerincomeandwealthprofiles.Oneisjustaslikelytoseea
8/9/2019 Remote Payments White Paper FINAL
8/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page7
mobilephonebeingusedonayachtcruisingintheMediterraneanasinthehandsofafruit
pickerinruralIndia.
Offeringconsumerservicesthatcanbedeliveredoveramobiledevicehasthepotentialto
reachan
unprecedented
proportion
of
global
consumers
and
businesses
like
no
other
consumerdevice.With thegrowthofmobilebroadband internet,thedistinctionbetween
mobilecommunicationsandmobilecomputingdevicesisblurring.
Already the latest smartphones offer a vast array of applications,just like computers,
ranging frompracticalprograms suchas spreadsheets tomobile television toall typesof
video games and entertainment packages. Tomorrows essential handheld device will
communicate, compute, and connect in an all in one integrated and convenient manner
actingasanindispensiblepersonalassistantnomatterwhatyoudoandwhereyoulive.
For institutions interested in providing mobile payments or financial services, the mobile
phonerepresentsnewopportunitiestoaccesscustomers.Themobilechannelcanactasa
virtualbranchthatcanofferbankingandpaymentservicestotheentirecustomerbase.
Inthephysicalworld,anumberofpilotsandpreliminaryprogrammeshavebeenrolledout
whereamobiledeviceisusedtopayforgoodsandservicesbytapping,touching,orwaving
at a contactless point of sale (POS) terminal. These are called proximity of mobile
contactlesspaymentsorNFC (NearFieldCommunication)payments.Thesepaymentsare
notwithinthescopeofthisdocument.
Thispaper is focusedonmobile remotepaymentswhichenable twoparties to sendand
receivepayments
or
exchange
funds
using
the
mobile
channel
irrespective
of
where
they
arelocated.Thesearedefinedinmoredetailinalatersection.Thepapercoversalltypesof
remotepaymentsforgoodsandservicesandthosethatsimplytransferfundsbetweentwo
ormoreparties(commonlycalledmobilemoneytransfers).
8/9/2019 Remote Payments White Paper FINAL
9/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page8
Background&Objectives
1. BACKGROUNDIn todays world, payments are made with various payment instruments, such as bank
accounts2, payment cards, and stored value accounts, using standardised payment
identifiers(e.g.,abankaccountorcreditcardaccountnumber).Whenapersonwantsto
payor transfer funds toanotherpersonorbusiness, theyareabletodosoby instructing
theirpaymentservicesprovider,suchasabankoracardcompany,totransfervaluefrom
theiraccounttothatofthereceiverorpayee.
Advances in payment systems technology, infrastructure, and channels mean that such
financialtransactions
can
be
made
over
anumber
of
channels
such
as
bank
branches,
POS
terminals, automated teller machines (ATMs), the internet (directly or via internet
banking),andnowovermobilephones.Thesechannelsaccommodatethecommonlyused
paymentinstrumentssuchasbankaccounts,paymentcards,andstoredvalueaccounts.
Akeycharacteristicofapaymenttransactionisthatitrequiresthepaymentidentifiersofall
partiestoapaymenttransaction.Inabankaccounttobankaccountelectronicpayment,the
payerprovidesthedetailsoftherecipientaccountnumberandrouting informationto
theirbank.Suchpayment identifiers, therefore, form thecoremechanismoverwhich the
routing,clearing,andsettlementofallpaymenttransactionstakesplace.
Inmobilecommunications,voiceanddatamessagingareroutedusingauniqueidentifier
referred to in this document as the Mobile Identifier or MID to identify the mobile
subscriber. In such communications the mobile phone number3 is used as the mobile
identifierorMID.
To develop a framework for facilitating mobile remote payments that are efficient and
convenient,thepaperstronglysuggeststhatthemobilephonenumber isusedastheMID
and not any other identifier for identifying, sending and receiving payments between
transactingparties.Inotherwords,whensomeonewantstoinitiateamobilepayment,they
need to know only the phone number of the recipient and not the details of their bank
account.
At theveryminimum, thereare threekeyreasons forusingthemobilephonenumberas
theMID theprimaryidentifierformobileremotepayments:
Convenience:Anewpayment instrument,method,orchannelmustofferacompelling
consumerexperiencebasedonaddedcustomerconveniencetobeattractivetousers.
2Throughout this document, a bank account refers to the relevant payment instruments such as credit transfers, standing
orders, and direct debits that access the account3
Mobile Subscriber Integrated Services Digital Network Number(MSISDN) in GSM standard terminology
8/9/2019 Remote Payments White Paper FINAL
10/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page9
Peoplealreadycommunicateusingphonenumbersandarehardly likely toaskothers
thedetailsoftheirbankaccountsorpaymentcardnumbersinordertomakepayments.
PrivacyandSecurity:Inadditiontoconvenience,anotherkeyconsiderationforusingthe
MIDfor
mobile
remote
payments
is
that
people,
in
general,
are
reluctant
to
share
their
financial details with others unless they trust them. In addition to identity theft,
unauthorised access to bank account or payment card details can result in payment
fraudandsignificant lossesforallstakeholders.Usingapaymentmechanismthatonly
requirestheMIDwhilekeepingthepaymentdetailsconfidentialensurestheintegrityof
aremotepaymentsystemandkeepsfinancialinformationprivate.
Interoperability:Notallpaymentsystemsare interoperable.Thesystemsandprotocols
leveragedbyVisaandMasterCardaretoa largeextentsimilarastheyfollowcommon
technical standards (for example, to interface with point of sale (POS) terminals at
merchantsor
cash
machines)
but
they
are
not
interoperable
with
each
other
(a
payment
onaVisacardcanonlybemade toamerchantwhoacceptsVisacardtransactions.A
VisamerchantwillnotacceptpaymentsmadewithaMasterCardcardproduct). Mobile
phonenumbers, on theotherhand, follow standardised topologiesandarebasedon
globalroutingandroamingstandards.Amobilesubscribercanidentifyandconnectwith
anothersubscribersimplyusingthemobilephonenumber.Toachievecriticalmassfor
mobile payments, this standardisation of mobile subscriber identification can be
leveraged,asfaraspracticaltomaximiseinteroperabilityacrossdiversemobilepayment
systems.The interoperabilitychallengeofmanymobilepaymentsystems is,therefore,
to leverage the flexibility of the mobile phone number to offer a high degree of
interoperability
in
order
to
maximize
the
usage
potential
by
consumers.
ThispaperalsorecognisesthattheMIDisoneofseveralpossibleidentifiersandisitselfnot
without challenges to implement, namely in terms of control and ownership, number
recyclingbyMNOsandcustomerchurn.
2. OBJECTIVESIn lightoftheabove,thispaperaimsatprovidingthestakeholdersofthemobilepayment
industrywith indicativeguidelinestodevelopecosystem(s)formobileremotepayments
that:
Areopenandinteroperable4
OfferconveniencethroughtheuseofmobileidentifiersorMIDs(thispapersuggests
theMIDisrepresentedbythemobilephonenumber)foridentifyingthesendingand
receivingentities
Leverageunderlyinginfrastructuresforexistingpaymentinstruments,suchasabank
account, payment card, or stored value accounts. The paper does not envisage
frameworksthatrequireentirelynewpaymentsystemstobedeveloped.
4For discussion on open and interoperable systems please refer to the next section
8/9/2019 Remote Payments White Paper FINAL
11/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page10
Theecosystemidentifiesthepartiesorstakeholdersandtheirrolesinitiating,processing,
andcompletingamobileremotepayment.
Itisimportanttonotethattheaimofthispaperistoprovideguidanceandamoreinformed
understandingof
commercially
and
operationally
viable
mobile
remote
payment
models.
Whilethepaperdescribesthecoreelementsofanecosystem,itdoesnotrecommendorin
any way prescribe an ideal mobile payments environment for a specific marketplace or
paymentservice. It isuptothe individualmobilepaymentproviderstodeveloptheirown
business models with pricing structures that reflect their business strategies and
competitivestrengths.
Coreoperationalprocessesdescribedandanalysedinthispaperareforillustrativepurposes
only.These incorporatetheminimumprocessrequirementstoensurethatmobileremote
payment transactionsare initiated securelyandaccurately andare completedefficiently.
These
process
descriptions
do
not
entail
any
recommendations
nor
any
proposals
for
standardisationofoperationalprocesses.
Important Note:Thepaper focusesonmobilepaymentsonly.Otherapplications suchas
mobilebankingorusingthemobiledevicesolelyforidentification,validation,orverification
purposesarebeyondthescopeofthispaper.
8/9/2019 Remote Payments White Paper FINAL
12/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page11
MobileRemotePayments
1. OVERVIEWMobile remote payments refer to payments that are initiated using a mobile
communicationsdeviceirrespectiveofthelocationofthepayerorthepayee.
Forthepurposesofthisdocument,thesedonotincludeproximity(contactless)payments,
whereamobile phone isusedas apointofsale terminal,orwhere the mobilephone is
usedpurelyforthepurposesofauthorisingatransaction.
Mobile remote payments can be classified into several use cases, some of which are
identifiedbelow
for
illustrative
purposes5.
The
key
criteria
for
such
classification
is
based
on
thetransactingpartiesinvolvedandthereasonsforundertakingthetransaction.
PersontoPerson(P2P):Transferoffundsfromoneindividualtoanotherusingamobile
devicealsoreferredtoasmobilemoneytransfers(MMT).Theseincludesocialpayments
(e.g.,payingforsharedexpensesetc).
International Remittances: A persontoperson / mobile money transfer across
international borders considered a separate category due to the relatively higher
paymentvalue,possibleforeignexchangerequirement,andregulatorycomplexity.
PersontoSmall Business (P2SB): Payments made by individuals for informal services(e.g., payments for babysitting or second hand items) or to formal sellers on a small
scale (e.g., self employed plumbers). These are more akin to persontoperson
payments.
PersontoBusiness(P2B):Paymentstobusinessesforgoodsandservices.This includes
all physical goods and services but excludes digital goods such as ring tones and bill
payments (considered separately). Conversely, also covered are businesstoperson
payments suchas those fordisbursementof salariesandwagesor reimbursementof
employeeexpenses.
Mobile Bill Payments: Payments usually made for utilities such as those for gas,
electricity,andwaterandothersimilarservicesnormally,butnotalways,incurredona
recurringbasis.Billpayment is related tobutdifferent frombillpresentmentwherea
billispresentedoveramobiledeviceforapprovaloracceptanceuponwhichapayment
maybeinitiatedusinganexistingarrangementsuchasastandingorder.
5Various alternative terms are also used: such as consumer in place of person, merchant in place of business
8/9/2019 Remote Payments White Paper FINAL
13/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page12
MCommerce:Payments fordigitalgoodssuchas ringtonesandsoftwareapplications
thataredownloadeddirectlyonto themobiledevice.A significantproportionof such
paymentsarebilledbythemobileoperator(s)providingtheservice.
Businessto
Business
(B2B):
Payments
or
funds
transfers
between
two
businesses.
These
could be payments for supply of goods and services and are usually large in value
relativetoretailpayments.
ImportantNotes:
Thepurposeof the listabove is to identifybroadmobile remotepaymentcategories.
Certain items and terms above may be used or interpreted differently in different
markets (such as the definition of a small business). The list is not meant to be
exhaustive.
To accommodate the rapid advancements taking place such as the expectedconvergence between mobile computing and mobile communications, payment
categoriesaredescribedinagenericsenseandarenotintendedtobeprecise.
2. ECOSYSTEMSTAKEHOLDERSDEFINITIONSANDROLESTherearevariousstakeholdersinvolvedandtheirrolesandresponsibilitiesaredescribedin
thispaper.Thecorestakeholderlistincludes:
2.1 PrimaryStakeholders Payer (or Sender): The payer uses a mobile device to initiate the payment
transactionwhichisprocessedthroughapaymentprovider.
Payers (orSenders)paymentprovider (PP):Apaymentprovidersuchasabank,a
card issuer,a remittanceagent,oraproviderof storedvalueaccountswhooffers
the mobile payment service to the payer. The payee's PP is responsible for
authenticatingthepayerandcomplyingwithallrelevantandapplicableKnowYour
Customer(KYC)andAntiMoneyLaundering(AML)regulations.
Payee (orReceiver):Thepayeecanbean individual,abusinesswhether informal,
small,large,
or
aregular
merchant
who
accepts
payments
over
various
channels
includingmobilechannels.
Payees (or Receivers) payment provider: A payment provider such as a bank,
remittance agent, card issuer, merchant acquirer, or a provider of stored value
accountswhoprovidesthemobilepaymentservicetothecustomer.Thepayee'sPP
would usually be providing the customer account to the receiver to which the
incomingpaymentwillbecredited.
8/9/2019 Remote Payments White Paper FINAL
14/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page13
2.2 EnablingStakeholdersThesearestakeholderswhodonotnecessarilyhaveadirectrelationshipwithcustomersbut
provide the enabling infrastructure over which a mobile remote payment is initiated,
processed,and
completed.
Mobile Network Operator (MNO): The operator will provide the messaging
infrastructure for text messages or other communication protocols that support
mobileremotepayments.MNOsarealsoreferredtoaswirelesscarriers.
Central Infrastructure Manager (CIM): In certain situations where a centralised
directoryservice isusedtoenablemobileremotepayments,thedirectoryprovider
will link a customers (a) mobile identifier or MID (normally the mobile phone
number)and (b) theirdefaultpayment instrumentsuchasacreditcardorabank
account.Thiswillenablethemobileidentifiertoactasaproxyorpseudonymforthe
cardor
account
number
to
facilitate
payments
over
existing
networks.
This
role
can
alsobefullyorpartiallyundertakenbyathirdpartytechnologyprovideroramobile
operator.TheCIMcanalsoofferandoperatecustomerauthenticationservices.
PaymentNetwork:Anexistingpaymentsystemoverwhichapaymenttransactionis
completedsuchasanAutomatedClearingHouse(ACH)orabilateralclearingservice
formoving fundsacrossbankaccountsorpayment cardnetworks suchasVisaor
MasterCard.
Handset Manufacturer: Handset manufacturers also play a significant role in the
ecosystembydevelopinghandsets thataredesigned to facilitatemobilepayments
andalso
through
relevant
value
added
services
such
as
application
pre
loading
whererelevant.
Application Providers and Others: Mobile applications are fast emerging on the
scene. They have generated a phenomenal level of demand from users of smart
phones. Payment providers will be able to design creative remote payment
applications for their customers. Application design and ease of use will serve as
significantcompetitive features.Other stakeholders, forexample, SecureElement
(SE) manufacturers may also provide relevant services such as secure application
storage.
Government
or
Regulatory
Entities:
Government
organisations
and
regulatory
bodies
aim to have relevant rules and regulations in place that keep payment systems
secureandensurethattheinterestsofconsumersandotherpaymentsystemusers
aresafeguardedandprotected.
8/9/2019 Remote Payments White Paper FINAL
15/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page14
2.3 ProcessValueChainA series of core processes enable a mobile remote payment to be initiated and
completed.Atahighlevel,relevantprocessesofthevaluechainaredescribedbelow.
CustomerAcquisition:Thisisanexistingprocesswithinapaymentprovider.Thisrelates
tomarketing and campaign management inorder toacquire new customers.Though
part of the overall value chain, it is relevant to all types of transactions and notjust
mobileremotepayments.Itisnotcoveredinthispaper.
CustomerRegistration&AccountSetup:Acustomeraftersigningupfortheservicewill
needtoprovideadditionaldetailsforthecustomerrecordtobesetupfortheservice
onthepaymentprovider'ssystems.Thisprocessisexplainedlaterinthispaper.
Send/RequestPayment:Thisprocessisdefinedseparatelyforsendingandrequestinga
payment.Thisprocessformsthecoreofthispaperintermsofsuggestedguidelines.
TransactionProcessing;ClearingandSettlement:Theseareessentialprocessesforany
payment
transaction.
The
paper
envisages
mobile
remote
payment
services
to
leverage
existingpaymentinfrastructure.Therefore,theseprocessesarethoseutilisedinexisting
paymentsystemsandnotcoveredhere.
Therearecertainadditionalsupportingprocessthatarelistedbelow:
Customer support: The essential minimum level of customer support that should be
providedissuggestedinthispaper.
RiskManagement;Legal&RegulatoryCompliance:Criticaltoanypaymentsystembut
as riskmanagementpoliciesaswellas legaland regulatoryguidelinesand regulations
aredifferentacrossmarkets,theseareoutofthescopeofthispaper.
3. MOBILEREMOTEPAYMENTSECOSYSTEMThissectionlaysoutanoverviewofaframeworkforenablingmobileremotepaymentsover
openand secureenvironments that leverageexisting payments infrastructuresoffering a
quickandpragmaticroutetomassmarketacceptanceofmobileremotepayments.
3.1 ProprietaryPaymentSystemsProprietarypaymentsystemsusuallyrequireboththepayerandthepayeetohaveaccounts
withthe
same
payment
provider.
These
are
also
called
closed
loop
or
three
party
paymentsystems.
Clearing &Settlement
TransactionProcessing
Send / RequestPayment
Registration &Set-up
CustomerAcquisition
Existing process not covered in
this paper
Specific mobile remote paymentprocesses covered in this paper
Existing processes (depending on thetype of payment instrument used) not
covered in this paper
8/9/2019 Remote Payments White Paper FINAL
16/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page15
Proprietary payment systems deal directly with endcustomers. PayPal, for example,
requires senders and receivers of funds to be registered with PayPal. Western Union,
despiteitswideglobalreach,isaproprietarypaymentsystemasitdealsdirectlywithend
customersandonlysupportstransferswithinanetworkofcertifiedWesternUnionagents.
These systems are generally not interoperable with other payment systems. However, a
proprietary system can interface with other proprietary systems on a bilateral basis or,
moreimportantly,withanopenpaymentsystem(seebelow)complyingwithstandardsand
formats prescribed by that system. PayPal, a proprietary system interfaces with open
bankingsystemsforthepurposesofdepositingandwithdrawingfunds.
3.2 OpenPaymentSystemsAn open payment system does not generally deal directly with endcustomers or offer
thempayment
accounts.
Payment
providers
who
participate
in
an
open
payment
system
offer interoperable payment services to their end users These payment providers are
separatecommercialentitiesanddealdirectlywiththeirownendcustomers.
Card payment networks such as Visa and MasterCard are examples of open payment
systems because they do not deal directly with endcustomers but enable participating
financial institutions to offer payment services to their endcustomers so that these
customerscanmakepaymentswhereverVisaorMasterCardpaymentsareaccepted.
Similarly,anACHusingSWIFTglobalmessagingstandardbasedonISO20022forauthorising,
clearingandsettlingaccounttoaccountcredittransferbetweenbanksisanexampleofan
openpayment
system.
The
ACH
executes
the
credit
transfer
between
banks
without
dealing
with endcustomers and uses a standardised messaging infrastructure for payments
instructionsreferredtoastheinterbankpaymentinteroperabilitydomain.
ImportantNotes:
Mobileremotepaymentecosystemmodelsdescribed in thisdocumentrelate toopen
paymentsystemswhichallowmultipleentitiestotransactwitheachother.
It is important to indicate here that payment systems may follow industry accepted
formatsand
technology
standards
but
may
still
opt
to
remain
proprietary.
Such
systems
willfinditrelativelyeasiertobecomeinteroperablewithothersystemsatalaterstage
when they choose to do so compared to systems developed on unique proprietary
standards.
8/9/2019 Remote Payments White Paper FINAL
17/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page16
4. ECOSYSTEMREQUIREMENTSThere are certain key requirements that are integral to a mobile remote payment
ecosystemirrespectiveofthemarketplaceorgeographicregionofactivity.
Please note that proprietary payment systems are also considered and discussed in this
papertotheextentthatanopenpaymentecosystemisabletoprovideaninteroperability
bridgeacrosssuchsystems(SeeLevel2 Intermediatelevelbelow).
1. INTEROPERABILITYForthedevelopmentofanopenmobileremotepaymentenvironment, it is important
forstakeholderstoreviewdifferentavailableinteroperabilityoptions.
Thisdocumentenvisagesthreeinteroperabilityoptions.Eachmarketmayfollowitsown
approachthat
best
suits
its
needs.
The
operational
processes
described
later
in
this
paper focus on different interoperability options in order to provide helpful and
pragmaticimplementationsuggestionsfordevelopingmobilepaymentservices.
The three broad interoperability options described below link to the three operating
modelsdescribedlaterinthisdocument:
Level1 Existing:This relates topaymentecosystems thatoperatewithinexisting
levelsandlimitationsofcurrentpaymentsystems
Level
2
Intermediate:
An
expanded
level
of
interoperability
that
provides
a
bridge
between two or more payment systems that are presently not interoperable. For
example:Paymentfromacustomerofapaymentsystemtoacustomerofanother
systemwherethetwosystemsarenotpresentlyinteroperable
Level 3 Direct or Extended: A level of interoperability where mobile remote
payments are undertaken in agreed transaction formats and in compliance with
open and shared standards. Whether a payment between a payer and payee is
completeddirectlyorfacilitatedbyoneormoreentities,underthisinteroperability
option, a payment transaction is generated, received, processed and completed
usingcommonstandardsthatareuniversallyacceptedirrespectiveoftechnologyor
underlyingprocesses.
2. EXISTINGPAYMENTSINFRASTRUCTUREThegeneralguidancesuppliedbythisdocumentstressesthe importanceof leveraging
existingpaymentinfrastructures.Whilethisisnotamandatoryrequirement,quicktime
to market can only be achieved through utilising existing technology and underlying
systems rather than creating entirely new structures for supporting mobile remote
payments. This will also help minimise additional infrastructure investments to the
extentpossible.
8/9/2019 Remote Payments White Paper FINAL
18/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page17
3. SECURITYA foremost requirement for offering mobile remote payments is to ensure that all
payment transactions are initiated and completed in a secure manner. Supporting
systemsand
processes
should
be
in
place
to
mitigate
operational
and
financial
risks.
Established payment systems have developed effective procedures relating to risk
managementsuchasfraudpreventionandauthenticationprocesses.Authenticationfor
authorised users is a key factor to assure customers and businesses that a mobile
payment isnot likely tobe fraudulentandwhere relevant, tocontrolnonrepudiation
andtoestablishdefinedliabilitiesincaseofanyclaim.
5. ECOSYSTEMCOMPONENTSThree core components of a mobile remote payment ecosystem enable a paymenttransactiontobesecurelyandsuccessfullycompleted.Thesearediscussedbelow:
COMPONENT1: MESSAGING(ORCOMMUNICATIONS)
Messagesbetween the variousparties toapayment transactionare crucial.A
payerneedstoknowwhenapaymentwasauthorised,approved,orcompleted
Fora receiveritiscriticaltoknowthestatusofapaymentsothatadecisioncan
bemadetoreleasegoodsoracknowledgereceipttocompletethetransaction.
Formobileremotepayments,communicationscantakeplaceutilisingavariety
ofavailabletechnologies.
It is highly likely that mobile network operators (MNOs) will provide the
infrastructureformessagetransport.
1. Messaging
2. PaymentFacilitation
3. FundsMovement
Retail bank
Card issuer
Payment servicesprovider
Payer Payee
PayersPaymentProvider
Remittance agent Retail bank
Card issuer
Merchant acquirer Payment services
provider
PayeesPaymentProvider
viaPayment Networks
(ACH, Card network, SVAsystems)
viaMobile Operator
Various ModelsIdentified in this
document
1. Messaging
2. PaymentFacilitation
3. FundsMovement
Retail bank
Card issuer
Payment servicesprovider
Payer Payee
PayersPaymentProvider
Remittance agent Retail bank
Card issuer
Merchant acquirer Payment services
provider
PayeesPaymentProvider
viaPayment Networks
(ACH, Card network, SVAsystems)
viaMobile Operator
Various ModelsIdentified in this
document
8/9/2019 Remote Payments White Paper FINAL
19/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page18
COMPONENT2:PAYMENTFACILITATION
The payment facilitation component assists in identifying the payment
instrumentsusedbythetwopartiestoapaymenttransaction.
Variousmodelsareavailable.Thetwopartiesmayvoluntarilydisclosepayment
instrumentdetailstoeachother;theymayrelyonsomeformoflinkage(through
a shareddirectoryor some other facilitatingasset)betweenmobile identifiers
and payment instruments belonging to the transacting parties; or may deploy
and/or complywithcommonmobilepaymenttransactionstandardstomake
paymentstoeachother.
COMPONENT3:FUNDSMOVEMENT
Actual transfer of value or movement of funds will take place using available
paymentnetworks.
A
majority
of
payments
in
any
market
are
processed
leveragingthreewidelyusedpaymentinstruments:
o BankaccountsoverACHandotherinterbankpaymentsystems
o Payment cards (debit, credit, charge and others) over global,
regional,andlocalpaymentcardnetworks
o Stored value accounts (PayPal, Obopay etc.) over proprietary
networks thatmayor maynot interfacewithbankingandpayment
cardnetworks.
Important Note: The guidance provided in this document stresses the importance of
leveragingtheseexistingpaymentinstruments.
8/9/2019 Remote Payments White Paper FINAL
20/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page19
6. INITIALIMPLEMENTATIONGUIDELINESForeaseofplanningandimplementation,thefollowingsetofguidelinesisprovidedfor
theinitialstagesofecosystemdevelopment.
PaymentInstrumentsinScope:Therearethreecorepaymentinstrumentswhichare
responsible for an overwhelming majority of global payments transactions. These
are(a)Bankaccounts(b)Paymentcardssuchascredit,charge,debitorprepaid(c)
storedvalueaccounts suchasPayPal.Theecosystemenvisioned in thisdocument
takesthesethreeinstrumenttypesintoconsideration.
Atthisstagepaymentschargedtoamobileoperatorbillorprepaidairtimeaccount
areexcludedfromthescopeofthisdocument.
Default Payment Instrument (DPI): Some markets for commercialor legal reasons
may require the customer tobeable to setupand select frommultiplepayment
instruments. However, to achieve quick speed to market, it is expected that a
customerwillbeabletosetupasinglepaymentinstrumentasthedefaultpayment
instrument, to send and receive funds. As services mature, there will be greater
choiceavailabletousers intermsofthenumberandtypeofpayment instruments
(seenextsectiononfutureguidelines).
Pleasenote that thisguideline is includedhere for the solepurposeof facilitating
quick implementations.Remotemobilepaymentecosystemsarefreetoselectand
implementservicesthatallowtheuseofmultiplepaymentinstruments.
Flexible User Interface (UI): The UI should be designed and developed by the
paymentproviderandshouldserveasanareaofcompetitiveservicedifferentiation.
CommunicationOptions:Thereareseveraltechnologyoptionsavailabletoproviders
ofmobileremotepayments.Thispaperdoesnotindicateorrecommendinanyform
thetypeofcommunicationprotocoltobeused.
PaymentTransactionsFormats:Existing transaction formatsshouldbedeployedas
faraspractical.Ultimatelyasmobileremotepaymentvolumesgrowsomeformof
common
standards
and
payment
transaction
formats
which
preferably
extend
the
existingformatsmayneedtobeagreedamongststakeholders(seenextsectionon
futureguidelines).
OperationalRulesandRegulations:Theopenecosystemwill leveragetheoperating
rules and regulations of the payment networks that are used for mobile remote
payments.Forexample,amobileremotepayment thatusesacreditordebitcard
accountwillbesubjecttoexistingdisputemanagementandchargebackrulesofthe
payment scheme (such as Visa or MasterCard). Some payment instruments are
preferred for certain use cases because of their key characteristics. For example,
paymentcardsprovide immediatepaymentguarantee tomerchantsso thatgoods
andservices
can
be
released.
8/9/2019 Remote Payments White Paper FINAL
21/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page20
Speed of Payment: The mobile ecosystem does not propose to develop a special
purpose real time payment system or a new system that provides an immediate
payment guarantee to the receiver. It is assumed that the payment guarantee
proceduresandpaymentsettlementtimeframesoftheunderlyingpaymentnetwork
willgovern
when
and
how
amobile
remote
payment
is
completed.
Depending
upon
theunderlyingpaymentsystemprocesses,atransactioncouldbesettledinamatter
of seconds (in case of near real time systems such as United Kingdoms Faster
Paymentsservice)ormaytakeuptoseveraldays. It is importanttonoteherethat
certain payment instrumentsaremore suitable to specificpayment categories (or
usecases).Forexample, forpersontobusinesspaymentswheregoodsorservices
are to be delivered, immediate settlement or a payment guarantee is usually
preferredbythemerchantsothatdeliverycanbeundertakenwithoutrisk.Insuch
casespaymentcardsaremoreappropriateastheseofferthemerchantaguaranteed
paymentforthetransaction.
Amarketorapaymentprovidermayprovideadditionalvalueaddedservicessuchas
an immediate payment guarantee or near real time settlement. These would be
consideredinthecompetitivedomainandbeyondthescopeofthispaper.
7. FUTUREIMPLEMENTATIONGUIDELINESAssystemsmatureandmobileremotepaymentactivitymovestowardsmassmarket
adoption,additionalfeaturescanbedevelopedasnecessaryandinconjunctionwith
customerdemand.
MultiplePaymentInstruments:Customerswillbeabletoselectfromawidevariety
ofpaymentinstrumentstosendandreceivefundsusingamobiledevice.However,
asstatedearlier,thismaybeaday1requirementinsomemarketsdueto
commercialorlegalreasons
MobilePaymentTransactionFormats:Standardisationwillensurethatmobile
remotepaymentsaremadeinuniversallyagreedtransactionformats.Thiswillalso
allownewplayerstoentertheindustryandoffernewpaymentproductsand
servicesusingcommonandopenstandards
Real/Near
Real
Time
Payment:
Developing
additional
infrastructure
elements
that
willfacilitatemobileremotepaymentstobecompletedinrealornearrealtime.
Suchenhancementsmaybeimplementedformobilepaymentsonlyorforall
electronicpaymentswithinacertainmarketasisthecasewithUnitedKingdom
throughtheFasterPaymentsservice.
8/9/2019 Remote Payments White Paper FINAL
22/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page21
OperatingModels
1. OVERVIEWThissectionidentifiesinfrastructurecomponentsand technologyelementsthatneedtobe
inplace for thedevelopmentofapragmaticand interoperable industrywideapproach to
facilitatemobileremotepayments.
2. MODEL1: COMMONINFRASTRUCTUREMODELThe model corresponds to Level 1 existing interoperability. This model proposes the
developmentof sharedorcommon infrastructure (CI) thatallows the routingofpayment
transactionsbased
on
the
mobile
identifier
(MID).
The
mobile
payment
industry
should
aim
at developing interoperable directory services that link a customers MID with the
associated payment instrument registered by the customer. In a fully centralised
environment(seecentralisedimplementationscenariobelow),thedirectoryserviceshould
supportaqueryprotocoltoretrievethepayment instrumentdetailsusingtheMIDof the
parties registeredforpreparingpaymentinstructionsandsubmittingtheseforprocessing,
clearingandsettlementover,asfarasapplicable,existingpaymentsystemssuchasACHor
cardnetworks.
Theretrievalandmatchingprocedureinthismodelvariesaccordingtotheimplementation
scenariosas
explained
below.
2.1 ImplementationScenarios1. Centralised: A centralised implementation scenario refers to a system where mobile
ecosystemstakeholdersshareacommoninfrastructure(CI)directorylinkingapayment
instrumenttoamobileidentifier(MID)
2. Distributed: In this scenario, each payment provider (such as a bank) develops and
maintainsitsowndirectoryofregisteredcustomers.Thecentralisedinfrastructureonly
providesa linkbetweenbank identifiercode (BIC)andtheMID.Here,theconfidential
databasecontaining
payment
instrument
details
is
decentralised.
Common Infrastructure can also be expanded in terms of one or more international
directoryservices linkingnationalorregionaldirectories thatoperateona logicsimilar to
the domain name service (DNS) on the internet for routing payment transactions across
nationalorregionalboundaries.
8/9/2019 Remote Payments White Paper FINAL
23/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page22
2.2 CentralisedImplementationScenarioThisscenarioenvisagesadatabasemanagedandmaintainedcentrally.Thiscouldbesetup
andmanagedby anexternalentity, called the central infrastructuremanager (CIM)ona
commercialbasis.
The
entity
could
be
apayments
infrastructure
services
provider
operating
on its own or on behalf of a competent authority such as a payment association or
consortiumofpaymentprovidersinaspecificmarket.
ThedirectorycontainstheMIDsofcustomersofpaymentproviderswhohaveregisteredto
use the mobile remote payment service and their default payment instrument (DPI) as
suppliedbythosecustomers.
InitiallyitissuggestedthattheDPIshouldbeasinglepaymentinstrumentforthepurposes
ofsendingandreceivingamobilepaymenttransactionor,alternatively,twoinstruments
oneforsendingandtheanotherforreceiving.Ata laterstageadditionalpaymentoptions
maybeadded.
Advantages
Minimum investmentforpaymentproviders:Inthismodelmostoftheupfront investment
in terms of infrastructure development is undertaken by the CIM who also ensures that
adequateproceduresandprocessesareinplacetoensuresystemavailability,integrity,and
security.
Speed of transaction: With centralised infrastructure, transactions can be routed and
processed quickly. A single database will complete transactions and deal with exception
itemsquickerthanonethatisdistributedandmaintainedbyseveralentities.
1. Messaging
CentralisedDirectory
A centrally managedand maintained
database that links
Mobile Identifiers(MID) with financialaccounts such as
bank, card, or SVAaccounts
3. FundsMovement
2. PaymentFacilitation
Payer Payee
PayersPayment
Provider
PayeesPayment
Provider
1. Messaging
CentralisedDirectory
A centrally managedand maintained
database that links
Mobile Identifiers(MID) with financialaccounts such as
bank, card, or SVAaccounts
3. FundsMovement
2. PaymentFacilitation
Payer Payee
PayersPayment
Provider
PayeesPayment
Provider
8/9/2019 Remote Payments White Paper FINAL
24/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page23
Efficiency: Updates to the central database will be applied to the entire directory
infrastructurewithverylittlemanagementandmaintenancetobeundertakenbyindividual
participatingpaymentproviders.
Time
to
market:The
time
necessary
to
implement
the
centralised
infrastructure
and
connect payment providers is expected to be less than the time required if all payment
providersdeveloptheirownsystemsthatmatchMIDswithpaymentinstruments.
Disadvantages
Security: The central database will store confidential customer financial information. This
maycreate security relatedaswellasconsumerdataprotection issues inmarketswhere
there are strict privacy and data management regulations in force. It may also not be
advisable inmarketswherestorageofsensitive financial informationatacentral location
andmanagedbyathirdpartyisconsideredapotentialareaofregulatoryconcern.TheCIM
will need to ensure suitable compliance with industry standards relating to stored bank
accountandpaymentcarddata.
Maintenance: Processes will have tobedevised andoperated to ensure that the central
directory iskeptuptodateandavailableatalltimes.Thiswillbeakeychallengebutmay
serveasadifferentiating featurewhere therearecompetingCIMs in themarketplace. If
customers change theirMID, report their handsets stolen,or change payment providers,
their details will need to be updated quickly and accurately so that the service remains
effective.
8/9/2019 Remote Payments White Paper FINAL
25/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page24
2.3 DistributedImplementationScenarioThedistributedmodelprovidesamoredecentralisedapproachwith thecentraldirectory
operatingonlyasatransactionswitch.Thecentraldirectoryinthiscasemanagesrecords
thatlink
MIDs
with
the
name
/detail
of
the
customers
payment
provider
and
switches
or
routespaymenttransactionstotheappropriatepaymentprovider.
EachpaymentprovidermaintainsandmanagesaseparatedirectorydatabaseofMIDsand
account data relating to their customers. Unlike the centralised model, confidential
customeraccountdataiskeptconfidentiallybythecustomerspaymentproviderandnotby
aseparateentity.
Advantages
Securityanddataprotection:Paymentproviderswillmanagetheirowndirectoriessothat
confidential
information
is
retained
by
the
them
and
not
by
a
third
party
managing
a
centralisedsystem.AssuchtheCIMwillonlyfunctionasapaymenttransactionswitch.
Control:Paymentprovidershavecontrolovertheircustomerrecordsintermsofhowoften
theseareupdatedandwhatstepsaretakentoremove,suspend,ormodifyrecordsincase
ofderegistrationsorterminationsduetolosthandsets.
Disadvantages
Additional investments:Paymentproviders inthisscenariomustsetupandmaintaintheir
own database directories and therefore this scenario requires upfront investment.
Participatingpayment
providers
will
need
to
implement
supporting
operational
processes
to
* Database that link Mobile Identifiers (MID) with financial accounts for thePayment Providers customers (maintained by the Payment Providers)
1. Messaging
Payment Switch
A centrally managedand maintained
switch based on adirectory linkingMobile Identifiers
(MID) with PaymentProvider details
ONLY
3. FundsMovement
2. Payment
Facilitation
PaymentProviderSpecific
Directory *
PaymentProviderSpecific
Directory *
Payer Payee
PayersPaymentProvider
PayeesPaymentProvider
* Database that link Mobile Identifiers (MID) with financial accounts for thePayment Providers customers (maintained by the Payment Providers)
1. Messaging
Payment Switch
A centrally managedand maintained
switch based on adirectory linkingMobile Identifiers
(MID) with PaymentProvider details
ONLY
3. FundsMovement
2. Payment
Facilitation
PaymentProviderSpecific
Directory *
PaymentProviderSpecific
Directory *
Payer Payee
PayersPaymentProvider
PayeesPaymentProvider
1. Messaging
Payment Switch
A centrally managedand maintained
switch based on adirectory linkingMobile Identifiers
(MID) with PaymentProvider details
ONLY
3. FundsMovement
2. Payment
Facilitation
PaymentProviderSpecific
Directory *
PaymentProviderSpecific
Directory *
Payer Payee
PayersPaymentProvider
PayeesPaymentProvider
8/9/2019 Remote Payments White Paper FINAL
26/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page25
ensuretheserecordsareupdatedinatimelymanner.Howeveritisexpectedthatthislevel
ofcustomerdatawillalreadybeavailableatmanypaymentproviders.
Efficiency: In a system where there are several hundred or several thousand payment
providersparticipating,
there
are
bound
to
be
operational
as
well
as
other
technical
issues
thatwillhavetobeaddressedbyindividualentities.Ifthesearenotresolvedinatimelyand
efficientmanner,itislikelythatthisscenariomayberelativelyinefficientcomparedtothe
oneaboveandresultinahighernumberofexceptionitems.
Time to market: As every payment provider will need to develop their own confidential
database linkingMIDstopayment instruments,thetimerequiredforanecosystemtobe
implementedonawidescalemaybeconsiderable.
3. MODEL2:INTERMEDIATEINTEROPERABILITYMODELThis model relates to Level 2 intermediate interoperability. The intermediate
interoperability model is an extension of the model discussed above. In this model, the
Common Infrastructure Manager (CIM) provides additional services to bridge the
interoperabilitygapacrossdifferentclosedloopsystemsandacrossopensystemsthatare
currentlynotinteroperable.
This model does not propose new transaction formats or make any standardisation
recommendations.TheactualframeworkormodeldesignwilldependontheCIMandmay
varyfrommarkettomarket.
Examples(for
illustrative
purposes
only):
AcustomerwithaVisacardmakingapayment toacardholder/merchantwitha
MasterCardaccount
Acustomerwith,sayaPayPalaccount,makingapaymenttoacustomerwithsay,an
Obopayaccount
Tokeep themodel simplewithout theneed fordevelopingnew technology standardsor
infrastructure,onepossibleavenueisfortheCIMtoopenandmaintainaccountsineachof
the three party systems it aims to bridge. Under this arrangement, the CIM will open a
control account with payment system A and a control account with payment system B
whereAandBarepresentlynot interoperablepaymentsystems.Acustomerofpayment
systemAwillbeabletomakeapaymenttoacustomerofpaymentsystemBbytransferring
funds to the CIMs control account with payment system A. The transaction will carry
payment instructions along with beneficiary details. The CIM will in turn transfer the
amountfromitsaccounttothebeneficiarysaccountwithpaymentsystemB.TheCIMwill
internallymakethenecessaryaccountingentriestoensurecompletionofthetransaction.
In thisway,noadditional infrastructure isrequiredand thetransactioncanbecompleted
using mechanisms within existing system capabilities. Additional technology elements,
especiallytoaccommodatepaymentmessagingbetweentheCIM,thepayer,andthepayee
willhave
to
be
developed
by
the
CIM.
8/9/2019 Remote Payments White Paper FINAL
27/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page26
1. Messagingand PaymentFacilitation
2. FundsMovement
Payer Payee
PayersPayment
Provider
PayeesPaymentProvider
viaPayment Networks(ACH, Card network, SVA
systems)
viaMobile Operator
direct
Orviap
ayme
ntpro
vider
1. Messagingand PaymentFacilitation
2. FundsMovement
Payer Payee
PayersPayment
Provider
PayeesPaymentProvider
viaPayment Networks(ACH, Card network, SVA
systems)
viaMobile Operator
direct
Orviap
ayme
ntpro
vider
Besides technology changes, it is possible that special negotiations and permissions from
existingpaymentsystemswillbenecessarytoimplementthismodel. Inconsequence,new
operationalproceduresandregulationscouldappearaswell.
4. MODEL3:DIRECTINTEROPERABILITYMODELThis model corresponds to Level 3 direct interoperability. This model suggests direct
paymentmessagingandfacilitationbetweenthepayerandthepayeewithouttheneedfor
anycommoninfrastructure.
A key requirement of the model is that an open standardised mobile payment message
formatisagreedbyallthestakeholders.Thepaymentproviderswillthenaccordinglymake
systemchangeswithintheirexistingtechnologysystemsanddevelopsuitableinterfacesto
processsuchpaymentmessages.
Anewinteroperablemessaging/transactionformatwillhavetobedevelopedortheexisting
messaging/transactionformatwillneedtobeenhancedinordertouse theMIDaspayment
instrument identifier for parties. Based on current thinking, the ISO20022 messaging
standard for financial transactions inXML formatsupportsmultiple typeofdata fields for
accountidentifiersandcanbeleveragedtoincludetheMIDasanaccountidentifier.Older
card payment messaging standard such as ISO8583 support the card number only as a
payment instrument identifier and are not suitable for including MID as the payment
instrumentidentifier.
Thepayerwilluseanapplicationoranonlinesitetopreparethepaymentinstructionsusing
anacceptableindustrystandardsecurityarrangementsuchasPublicKeyInfrastructure(PKI)
technology, and send the payment message to the receiver. The transaction format will
needtobestandardisedandagreed.Thereceiverwillforwardthemessagetoitspayment
provider, such as a bank or a card company, who will read the message and process it
accordingly using existing payments infrastructure. For example, the payment instruction
after receipt by the receivers payment provider may be treated exactly as an ACH
transactionforclearing,settlement,andcompletion.
8/9/2019 Remote Payments White Paper FINAL
28/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page27
Thereareanumberofalternativeshowtheprocessmaybeimplemented.Inadditiontothe
messagesentbythepayerdirectlytothepayee,itmaybepossibleforthepayertoprepare
and send a mobile message with instructions to initiate the transaction to its payment
provider (see illustration above). This may be a better alternative from a security
perspective.The
payers
payment
provider
will
then
send
the
message
directly
to
the
receiverwhowillsubmitittotheirpaymentprovider.
8/9/2019 Remote Payments White Paper FINAL
29/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page28
GapAnalysis
1. OVERVIEWA key point of consideration in envisioning a mobile remote payments ecosystem in this
document is thatsuchanecosystemandall relatedoperationalmodels,ashighlighted in
previous sections, should leverage existingpayment instruments andpayment systems
infrastructure networks used for facilitating electronic payments. This will ensure that
mobilepaymentsutiliseexistinginvestmentsandpaymentprovidersareabletodesignand
launch mobile payment offerings in the most optimal timeframes possible. The ultimate
industryobjective istoensurethatpaymentsystemsareavailablethatcanhandlemobile
remote payments on a commercial scale in markets across the globe securely and
efficiently.
The gap between todays payment systems and those envisioned in this document is
discussedinthissection.Additionalelementsandenhancementstotheexistingsystemswill
needtobeundertakenbysomeorallthestakeholdersarediscussedbelow.
2. COMMONINFRASTRUCTURE(CI)Commoninfrastructurereferstomodels1and2(existingandintermediateinteroperability)
and consists of a directory service linking MIDs to financial account data. Common
InfrastructureManager
(CIM)
entities
will
need
to
be
set
up
to
manage
/own
the
new
assets.
To support such a directory, operational processes will have to be designed and
implementedforcustomerregistration,recordretrieval,paymentfacilitation,andpayment
processing. Customer data is sensitiveand, therefore, thedesign of thedirectory service
shouldpreservethesecurityandconfidentialityofmobileecosystemsowners.
The sizingand theperformance requirements for the registrationand retrievalprocesses
arecriticalwheremillionsofcustomersmightusetheserviceacrossmultiplecountries.
The
recorddata
format
should
be
based
on
international
messaging
standards
for
payments and enable unique mapping of the record data into instructions for payment
messages(theISO200022standard and theXMLformat/structureofthedebtor/creditor
accountblockaresuggestedassuitableforthispurpose).
Theretrievalprotocolshouldbestandardised,wherepossible inrealtime,andefficient in
termsof response time toaquery.Standardised industryprotocols fordirectory services
such as LDAP could be used. Model 2 further requires the setting up of accounts with
paymentsystemsthatarenotcurrentlyinteroperable.Thiswouldneedtobesupportedby
an enabling messaging and alert system toensureautomated communicationsof mobile
remotepayments.
8/9/2019 Remote Payments White Paper FINAL
30/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page29
Itisintendedthatsystemsandprocessesalreadyavailableforspecificpaymentinstruments
todealwithcustomerservice issues,disputemanagement,andexception itemprocessing
will continue to be used in a mobile environment. In other words, if a mobile remote
payment is cleared and settled using an ACH payment system, the relevant rules and
operatingregulations
of
that
system
will
also
apply
to
the
mobile
transaction.
Itisimportanttoidentifyandmonitormobiletransactionsfromtraditionalones,inorderto
giveallparticipantsthepossibilitytocontrolanddevelopspecificactionstopromotemobile
payments. It is advisable to implement process such as transaction identifiers or flags to
identifymobilepayment transactionsanddevelopreports toanalyse transactionpatterns
etc.
Additionally, where certain payment providers such as banks, plan to integrate mobile
payment systems within their mobile banking environments, they will require additional
infrastructure
development
which
is
beyond
the
scope
of
this
document.
3. STANDARDISATIONThestandardisationgapdescribedherereferstoModel3whichfacilitatesdirectmessaging
betweentwopartiestoapaymenttransactionthepayerandthepayeeusingagreedand
standardised message formats. Some form of client or server resident application or
protocolwillberequiredtoprepareanencryptedpaymentmessagethatwillbesenttothe
receiverdirectly.
For this model to be implemented, agreement across industry stakeholders on common
standardsand transaction formatswillbenecessary.These include thestandardisationof
thefollowingkeytransactioncomponents.Pleasenotethislistisnotexhaustive:
Paymentinitiationorrequestmessagepreparation
Securityandencryptionformatstobeused
Transactionformatthatincludesboththepaymentidentifierandthemobileidentifier
Proceduresand processes for processingor forwardingofencrypted messages to the
paymentprovider
for
processing
Proceduresandprocessesforhandlingincompleteorfailedtransactions
Systemofalertsandnotificationsforboththepayerandpayee
The effort towards standardisation, while necessary and optimal, generally requires
significanttimeandeffortforagreementandacceptanceespeciallywherestandardisation
isnecessaryonaglobalscale.
While detailed implementations will be solution specific, minimum standards will be
requiredto
be
agreed
and
complied
with.
8/9/2019 Remote Payments White Paper FINAL
31/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page30
CoreProcesses
1. OVERVIEWCertainprocesseswill have to be developed or enhancedbyprovidersofmobile remote
payments.Theseinclude,butarenotlimitedtothefollowing:
Registration&setup
Sendpayments
Requestpayments
Customersupport
Eachprocessabove isexplainedbelowatahighleveltogetherwithguidingprinciplesand,
where applicable, suggested process steps. Process activities are presented at a generic
levelandindividualmarketimplementationsmayvarysignificantlyfromeachother.
2. REGISTRATION&SETUPRegistrationandsetupactivitiesdiscussedinthissectionareprevalentprimarilyformodels
involving a common infrastructure. Where minimal or no common infrastructure is
envisioned,asinmodel3,differentregistrationoptionswillbeapplicable.
2.1 DescriptionPaymentproviders(PPs)mustestablishthatacustomerownsorhastheappropriaterights
tousethefinancialinstrumentstobeusedtoeithermakeorreceiveamobilepayment.
CustomersshouldbeabletoregisterwithmultiplePPstomakepayments. It isexpected
that customers will be automatically enabled to send and receive payments on initial
registration.Additionally, nominatingadefaultbeneficiarymayhelptosimplifyandspeed
thepaymentprocess.
The customers PP (sponsoring PP) should establish that the customer has correctly
registeredtheMIDofthemobilephonetobeusedtoreceiveapayment.Thecustomers
MIDcanberegisteredautomaticallyfrominformationsentbytheMNO,whenapplicable.
Customer registrationmaybeundertakendirectlybyaPP,orbyanagentactingon their
behalf.
TheservicerequiresthatPPsobtainalltheinformationfromcustomersrequiredinorderto
fullypopulateanentryontothecustomerinformation(CI)database.
8/9/2019 Remote Payments White Paper FINAL
32/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page31
CustomerName/Nickname
Mobilenumber(s).Customersmayregistertheirmobilephonenumberstothe
ServiceusingafullMIDoranationallevelnumber.Howeverthenumberwillalways
bestoredontheCIdatabaseasafullMID
SponsoringPPname
Paymentinstrumentdetails
Accountnameofthepaymentinstrument,ifapplicable
Customeridentitycode(allocatedbythecustomerssponsoringPP)
Customersmayregisterinoneoftwomodes:
toreceivepaymentsonly
to
send
and
receive
payments
PPsundertake topopulate the CIdatabasewith thedetailsof every customer that they
register to use the Service, whether or not they additionally operate a local database
system.
2.2 KeySteps(a)SponsoringPPgathersdatafromcustomerwishingtoregisterfortheservice.The
sponsoringPPmayenableanumberofchannelsincluding,onlinebanking,
telephonyand
branch
to
collect
data
(b)SponsoringPPestablishesthatthecustomerhaspossessionofthemobilephoneto
beusedandisresponsibleforallKYCandregulatorychecks
(c) SponsoringPPsendsdatatoCIdatabaseinrealtime
(d)CIdatabaseundertakesvaliditychecke.g.isthemobilephonenumberalready
registered?
(e) Ifso,CIdatabaseadvisesSponsoringPP.ThePPmaythenrejectentryandrequest
newdetails,oraskcustomertoconfirmthattheywishtochangeexisting
associationsoraddanewassociationtoanotherPP
(f) Ifnot,
CI
database
adds
new
entry
and
advises
Sponsoring
PP
(g)SponsoringPPadvisescustomerasappropriateandwhereapplicable,sends
customerauthenticationpasscodeviaasecuredeliverychannel.Thepasscodecan
eitherbedefinedbythecustomerduringtheregistrationphaseorbeautomatically
generatedbythesponsoringPP.
(h)Customeractivatesthemobilepaymentserviceusingthesuppliedcredentials.
8/9/2019 Remote Payments White Paper FINAL
33/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page32
2.3 ManagementandMaintenanceThissectioncontainstheprocessforupdatingcustomerrecords.
Generalprinciples
(a)AllchangestoCIdatabaserecordstakeeffectinrealtime
(b)Oldrecordsareretainedforaudittrailpurposes
(c) Allchangesareauthorisedbytheauthenticateduser
Option1.CustomerremainswithoriginalsponsoringPP
In cases where the customer wishes to amenddetailsof their record,but otherwise the
accountremainswiththeoriginalSponsoringPP,thefollowingprocessissuggested:
(a)CustomeradvisessponsoringPPofchangeofdata
(b)SponsoringPPestablishesthatthecustomerhaspossessionofthemobilephoneto
beused
(c) SponsoringPPsendsdatatoCIdatabaseinrealtime
(d)CIdatabaseundertakesdatavaliditychecks
(e) IfCIdatabaserejectsentry,SponsoringPPisadvised
(f) IfCIdatabaseacceptsentry,entryisupdated[inrealtime]andSponsoringPPis
advised
(g)SponsoringPP
advises
customer
accordingly.
Option2.CustomermovesrecordtoanewPP
Incaseswherethecustomerismovingtheassociationfortheirmobilephonenumberfrom
onePPtoanother,thePPtowhichtheassociationisbeingmovedto(theNewPP)takes
precedenceovertheoriginalsponsoringPP(theOldPP),asfollows:
(a)CustomeradvisesNewPPthattheywishtoassociatetheirmobilephonewithan
accountattheNewPP.NewPPmustfulfilalltherequirementsassociatedwithan
initialregistration.
(b)NewPPsendsdatatoCIdatabaseinrealtime
(c) CIdatabaseidentifiesthatachangeinsponsoringPPistakingplaceandinformsthe
OldPP
(d)CIdatabaseundertakesdatavaliditychecks
(e) IfCIdatabaserejectsentry,NewPPisadvised
(f) IfCIdatabaseacceptsentry,entryisupdatedinrealtime,andNewPPisadvised
(g)NewPPadvisescustomeraccordingly.
ThekeyrequirementisthatchangesinassociationfromonePPtoanothershouldappear
smoothandstraightforwardtothecustomer.
8/9/2019 Remote Payments White Paper FINAL
34/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page33
2.4 DeregistrationThis section contains the requirementsandprocess forpermanently removing customers
fromtheService.
Generalprinciples:
(a)Customersmaychoosetowithdrawfromtheservice
(b)PPsmayderegistercustomersfromtheservice,forexampleincasesofcustomer
inactivityormisuseofservice(oranyillegalactions)
(c) SponsoringPPsmaywishtoconsiderdeactivatingdormant/unusedentriesinorder
tomitigatethepossibilitythatanunusedmobilephonenumberhasbeenre
allocatedtoanothermobilephonecustomerbytheMobileNetworkOperator.In
thesecasesSponsoringPPsareencouragedtoattempttocontactthecustomer
priorto
deactivation.
(d)Whenentriesbecomedormant,therecordisflaggedassuchontheCIdatabase,and
thesponsoringPPundertakestoinformthecustomer
(e)Deactivatedrecordswillberetainedforauditpurposes.
(f) AccountdeactivationswillbereflectedontheCIdatabaseinrealtime
3. SENDPAYMENTS3.1 PaymenttransactionwithCICustomerswhohavecompletedtheregistrationprocessasdefinedinthediscussionabove
are ready to make mobile remote payments. This section describes a generic payment
processapproach,individualserviceandmarketoffersmaydifferasnecessary.
Asindicatedearlierinthispaper,whenapayermakesaremotemobilepaymenttoaknown
payee,themain identifierofthepayeeisauniquemobileIDwhichistypicallythepayees
phone number (MID)due to obvioususability benefitsoverother typesof mobile IDs or
accountnumbers.
The payment is made from payers chosen payment instrument, which can be a bank
account,credit/debitcardorastoredvalueaccount(SVA).Payeespaymentinstrumentcan
beanytype,butthepayerdoesnotneedtoknowwhattypepaymentinstrument(s)isheld
bythepayee.
Whenacustomerstartsapaymentprocess,he/shewillneedthefollowing:
- Payeesmobileidentifier(MID).
- AconnectedmobiledevicethatisregisteredtomakepaymentswiththepayersPP.
- Avalidandauthorisedpaymentaccount.
- Sufficientamountofcreditorvalueinthepaymentaccounttomaketherequested
payment.
8/9/2019 Remote Payments White Paper FINAL
35/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page34
- Requiredcredentialsforauthentication(e.g.PINcode,biometricID,token)
Suggestedprocesssteps:
Step# DescriptionMandatory/
Optional
1 Whenstartingapaymenttransactiontheusermighthaveconfiguredhis
mobiledevicetorequireanunlockcodetoaccessthepaymentapplication.
Thisstepisnotneededifpaymentisinitiatedbye.g.nativeSMSclientofthe
mobiledevice.Theunlockcodecanbevalidatedeitheronlineoroffline,
dependingontheunderlyingsecuritysolution.
Optional
2 Payerenterstheminimumamountofpaymentinformationforpayment
initiation.This
information
includes
(but
might
not
be
limited
to):
- Payeemobileidentifier(MID)
- Paymentamount
- Paymentinstrumenttobedebited(Optional)
- Paymentduedate(immediateorfuturedated)
- Message(optional)
Mandatory
3 Payerauthorisesthetransactionwithhis/hercredentials(e.g.PINcode).
Actualauthenticationmethodisdependentontheunderlyingsecurity
solution.
Inpractice
this
step
can
be
combined
with
step
2of
this
process
ifrequired
for
betterusability.
Mandatory
4 Paymentinformationandauthenticationinformationaresenttothepayers
PP.Technicalbearerissolutionspecific.
Itshouldbenotedthatsufficientlevelofencryptionshouldbeusedwhen
transmittingpaymentinformationfrommobiledevicetothePP.Detailed
encryptionalgorithmstrength,nonrepudiationandintegrityrequirements
aresolutionspecific.
Mandatory
5 PayerPPvalidatesandauthenticatestheincomingrequest.Incoming
paymentrequestshouldbevalidatedtohavecorrect
- Credentials(authentication)
- Mandatoryminimumpaymentinformation
AdditionallythepayerPPcanchoosetovalidatewhetherthecustomers
paymentinstrumenthassufficientcredittofacilitatethetransactionamount
atthisstage.Optionallythepaymentdetailscanbevalidatedonlywhen
executingthepaymenttowardsthepaymentnetwork.Itisalsooptionalto
validatelimitamounts,accumulateamountsornumberorpayments,defined
bythe
customer,
the
PP
and/or
regulations.
Mandatory
8/9/2019 Remote Payments White Paper FINAL
36/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page35
Step# DescriptionMandatory/
Optional
6 Ifpaymentisvalid,processiscontinuedinstep8.Ifnot,processisterminated
at
step
7.
Mandatory
7 Paymenttransactionisterminated.Userisinformedofthereasonforfailing
theinitialvalidation.
Mandatory
8 Validpaymentprocessingwillstartbyrequestingpayeepaymentinstrument
informationfromthedirectoryservice(CIM).
Mandatory
9 CIcheckswhetherthepayeehasregisteredhis/heraccountinstrumentwith
theservice.Incaseofadistributedscenario,thisinformationmightresidein
anotherdirectoryorregion.ItistheresponsibilityoftheCItotakethe
necessarystepstochecktheregistrationstatusofanyforwardedpayee
mobileidentifier,
regardless
of
payees
home
directory
location.
Ifpayeeisregistered(inanyofthedirectories),processcontinuesinstep11.
Ifpayeeisnotregisteredorhisaccountinstrumentisnotactive,theprocessis
terminatedinstep10.
Mandatory
10 Paymentprocessisterminated.Payerisinformedoffailedtransactionand
payeeisoptionallycontactedtoregisterfortheserviceoractivatehisaccount
instrument.
Itshouldbenotedthataviraldistributionprocesscanbeimplementedinthis
stage.This
would
keep
the
payment
process
running,
reserve
the
funds
from
payersaccountandcreditthepayeeaccountoncethepayeehasregistered
fortheservice.Detailsofthisprocessarenotdescribedinthiswhitepaper.
Mandatory
11 Payeesmobileidentifierismappedtoapaymentinstrumentrouting
informationandanickname.
Mandatory
12 Payerisaskedforapaymentconfirmationbasedongivenpayment
informationandnicknamereceivedinstep11.Payerwillnotseethepayees
fullnameorpaymentinstrumentinformationtoavoidprivacyissues.
Mandatory
13
Ifpayer
rejects
the
payment
confirmation
request,
the
process
ends.
Mandatory
14 Ifpayerapprovesthepaymentconfirmationrequest,thepayerPPstartsthe
paymentprocess.Thisprocessisdependentonwhattypeofpayment
instrumentisusedonbothsides.
Mandatory
15 Ifsupportedbythesystem,arealtimepaymentnotificationcanbegenerated
tonotifythepayeeofincomingpayment.
Realtimepaymentnotificationistypicallynotneededifthechosenpayment
methodandnetworksupportsrealtimeornearrealtimetransactions(e.g.
UKFasterPayments).
Optional
8/9/2019 Remote Payments White Paper FINAL
37/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page36
Step# DescriptionMandatory/
Optional
16 TheoptionalrealtimepaymentnotificationisgeneratedbytheDirectoryand
sent
to
payee
PP.
Optional
17 PayeePPcanchoosewhethertoroutethenotificationtothepayeeornot.
Typicallythiswouldbeavalueaddedserviceforcustomerswhohave
requestedtooptinforpaymentnotifications.
Optional
18 Anoptionalnotificationcanbesenttothepayeeonincomingpayments.
Notificationcancontainatleastamountandpayerinformation.Ifsupported
bythepaymentinstrumentusedandthepaymentnetwork,anestimated
timeforcreditingtheincomingfundsshouldalsobeprovided.
Optional
19 Thepaymentprocessisexecutedbytherulesandprocessessetbytheused
paymentinstruments.
Details
of
this
process
by
payment
instrument
are
not
inthescopeofthiswhitepaper.
Mandatory
20 Oncethepaymentprocessiscomplete,thepayeesaccountiscreditedwith
theappropriateamount.Notethattheamountcreditedmaydifferfromthe
initialpaymentamountdependingontheunderlyingbusiness andrevenue
sharingmodel.
Mandatory
21 Ifoptedinbythepayee,anotificationcanbesenttothepayeeoncethe
fundsarecredited.
Optional
22
Ifsupported
by
the
system,
apayment
confirmation
can
be
sent
through
to
thepayerPPoncefundsarecreditedtothepayeepaymentinstrument.Optional
23 Ifoptedinandsupportedbythesystem,aconfirmationofcompleted
paymentcanbeshowntothepayer.
Optional
3.2 PaymenttransactionwithoutCIAlternativelyapayment transactioncanbeexecutedwithamodel thatdoesnotuseaCI
servicefor
mapping
mobile
identifiers
to
payment
instruments.
In
this
model
messages
betweenpayer/payersPPandpayeearesentthroughtheoperatornetworkdirectlytothe
receivingmobiledevicebasedonthemobileidentifier(MID).
Thismodelrequiresthatthepaymentinstrumentidentifierorpayerbankidentifier(BIC)is
sentwitheachpaymentmessage.Inpracticethissetslimitationstothemessaginglayer,as
cleartextprotocols likeplainSMSusingnativemessagingclientscannotbeusedwithout
harmingtheusabilityoftheservice.
Toreemphasise,multipleimplementationscenariosarepossible.Thefollowingissuggested
forguidanceonly.
MaincharacteristicsofthepaymenttransactionaresimilartothetransactionwithCI.
8/9/2019 Remote Payments White Paper FINAL
38/56
MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems
Version1.0
ForPublicReview
CopyrightMobeyForumJune2010Allrightsreserved
Page37
Suggestedprocesssteps:
Step# DescriptionMandatory/
Optional
1 Whenstartingapaymenttransactiontheusermayhaveconfiguredhismobile
devicetorequireanunlockcodetoaccessthepaymentapplication.Thisstep
isnotneededifpaymentisinitiatedbye.g.nativeSMSclientofthemobile
device.Theunlockcodecanbevalidatedeitheronlineoroffline,depending
ontheunderlyingsecuritysolution.
Optional
2 Payerenterstheminimumamountofpaymentinformationforpayment
initiation.Thisinformationincludes(butmightnotbelimitedto):
- Payeemobileidentifier(MID)
- Paymentamount
- Paymentinstrumenttobedebited(Optional)
- Paymentduedate(immediateorfuturedated)
- Message(optional)
Mandatory
3 Payerauthorisesthetransactionwithhis/hercredentials(e.g.PINcode).
Actualauthenticationmethodisdependentontheunderlyingsecurity