Page 167 - The Digital Financial Services (DFS) Ecosystem

ITU-T Focus Group Digital Financial Services
Ecosystem

of the particular scheme. For example, if the merchant is privy to or may somehow gain access to sensitive
information (account numbers, passwords, etc.) that would argue for more thorough up front screening of
merchants in addition to normal risk management activities described below. Another example of merchant
underwriting could be ensuring that the merchant is a legitimate merchant entity (versus a shell company
that exists only to perpetrate fraud) and that the principals have not been barred/expelled from that scheme
in the past for wrongdoing.

2.1.3 Onboarding

After a merchant agrees to accept payments in the scheme and passes any upfront underwriting processes,
they must then be provisioned into the payment system(s). For example, irrespective of where the information
is held and by whom, information such as the merchant’s physical address, proprietor’s name and perhaps ID
number, type of merchant, expected average transaction amount (important for ongoing risk management),
etc. must be gathered and input into the applicable database(s).

Optimally, both the underwriting and onboarding processes should only have to be performed once, versus
redundant processes by the various payment schemes. This would require use of a trusted entity with access
to relevant information from a variety of sources. In addition, this process could be aided by utilizing a common
merchant identifier within and across payment schemes. Also, a common merchant identifier could also make
it easier for merchants to switch providers, fostering a more competitive marketplace.

2.1.4 Technology

Payment-related devices and software sales and service – some schemes could require or offer the option
of using specialized hardware and software to process transactions – for example, special smart phone
applications, phone peripherals, dedicated payment terminals, ecommerce payment modules, etc. In many/
most schemes, a provider is need to help configure the merchants’ payment acceptance hardware and software
to properly accept, process, and communicate transactions to the system. Sometimes this can be part of the
onboarding process or can be performed by a separate entity.

As with some other functions, the notion of which type of organization is best to perform this function is
principally driven by who is best positioned to offer the merchant a device and/or software that can accept
competing schemes via a single device and/or user interface (i.e., the schemes should be interoperable at the
point of sale device level). Ideally, merchants should not have to purchase multiple devices to support multiple
payment schemes and sales staff should not have to learn different payment processing procedures; rather,
the service and interfaces should be constructed such that it will be transparent to the merchant and clerks
which scheme is used by the customer.

This does not mean that the schemes will necessarily need to all agree on a common user point of sale
technology for all merchants. Rather, which technology is employed (NFC, bar code, sonic signals, etc.) will
likely be a function of the type of device the merchant is using (smart phone, feature phone, etc.) combined
with which type of device the customer has.

2.1.5 Pricing

Schemes vary widely in how transaction services are priced to payment acceptors. In some cases, the merchant
service provider essentially marks up a wholesale rate from the scheme to generate explicit profits. In other
cases, end prices to merchants could be set by the government or by the scheme itself, sometimes varying
based on type of merchant, how much volume the merchant processes, etc. Some schemes may have different
pricing structures, such as prepaid eMoneys vs. bill to carrier models.

139