Remote Payments White Paper FINAL

8/9/2019 Remote Payments White Paper FINAL

1/56

MOBEYFORUM

MobileRemotePayments

GeneralGuidelinesforEcosystems

WhitePaper

June2010


2/56

MobeyForum MobileRemotePayments:GeneralGuidelinesforEcosystems

Version1.0

ForPublicReview

CopyrightMobeyForumJune2010Allrightsreserved

Page1

June2010

Copyright2010MobeyForum

Allrightsreserved.Reproductionbyanymethodorunauthorised

circulationisstrictlyprohibited,andisaviolationofinternational

copyrightlaw.


3/56


Version1.0

ForPublicReview


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


4/56


Version1.0

ForPublicReview


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


5/56


Version1.0

ForPublicReview


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


6/56


Version1.0

ForPublicReview


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


7/56


Version1.0

ForPublicReview


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/56


Version1.0

ForPublicReview


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


9/56


Version1.0

ForPublicReview


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


10/56


Version1.0

ForPublicReview


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


11/56


Version1.0

ForPublicReview


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.


12/56


Version1.0

ForPublicReview


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


13/56


Version1.0

ForPublicReview


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.


14/56


Version1.0

ForPublicReview


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.


15/56


Version1.0

ForPublicReview


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


16/56


Version1.0

ForPublicReview


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.


17/56


Version1.0

ForPublicReview


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.


18/56


Version1.0

ForPublicReview


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


3. FundsMovement

Retail bank

Card issuer

Payment servicesprovider

Payer Payee


Remittance agent Retail bank

Card issuer

Merchant acquirer Payment services

provider


viaPayment Networks

(ACH, Card network, SVAsystems)

viaMobile Operator

Various ModelsIdentified in this

document


19/56


Version1.0

ForPublicReview


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.


20/56


Version1.0

ForPublicReview


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.


21/56


Version1.0

ForPublicReview


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.


22/56


Version1.0

ForPublicReview


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.


23/56


Version1.0

ForPublicReview


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


Payer Payee

PayersPayment

Provider

PayeesPayment

Provider

1. Messaging

CentralisedDirectory


database that links

Mobile Identifiers(MID) with financialaccounts such as

bank, card, or SVAaccounts

3. FundsMovement


Payer Payee

PayersPayment

Provider

PayeesPayment

Provider


24/56


Version1.0

ForPublicReview


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.


25/56


Version1.0

ForPublicReview


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


switch based on adirectory linkingMobile Identifiers

(MID) with PaymentProvider details

ONLY

3. FundsMovement

2. Payment

Facilitation

PaymentProviderSpecific

Directory *


Directory *

Payer Payee



* Database that link Mobile Identifiers (MID) with financial accounts for thePayment Providers customers (maintained by the Payment Providers)

1. Messaging

Payment Switch




ONLY

3. FundsMovement

2. Payment

Facilitation


Directory *


Directory *

Payer Payee



1. Messaging

Payment Switch




ONLY

3. FundsMovement

2. Payment

Facilitation


Directory *


Directory *

Payer Payee




26/56


Version1.0

ForPublicReview


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.


27/56


Version1.0

ForPublicReview


Page26

1. Messagingand PaymentFacilitation

2. FundsMovement

Payer Payee

PayersPayment

Provider


viaPayment Networks(ACH, Card network, SVA

systems)

viaMobile Operator

direct

Orviap

ayme

ntpro

vider

1. Messagingand PaymentFacilitation

2. FundsMovement

Payer Payee

PayersPayment

Provider


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.


28/56


Version1.0

ForPublicReview


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.


29/56


Version1.0

ForPublicReview


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.


30/56


Version1.0

ForPublicReview


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.


31/56


Version1.0

ForPublicReview


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.


32/56


Version1.0

ForPublicReview


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.


33/56


Version1.0

ForPublicReview


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.


34/56


Version1.0

ForPublicReview


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.


35/56


Version1.0

ForPublicReview


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


36/56


Version1.0

ForPublicReview


Page35


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


37/56


Version1.0

ForPublicReview


Page36


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.


38/56


Version1.0

ForPublicReview


Page37

Suggestedprocesssteps:


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

Documents

Remote Payments White Paper FINAL