Page 99 - ITU-T Focus Group Digital Financial Services – Technology, innovation and competition

ITU-T Focus Group Digital Financial Services
Technology, Innovation and Competition

Maximum value of transactions per day (calculated as maximum transferred amount per transaction times
the maximum number of transactions per day). There could be an option to set this limit for transfers from
each type of balance (airtime, mobile wallet, linked bank account).
Maximum number of transactions per month. There could be an option to set this limit for transfers from each
type of balance (airtime, mobile wallet, linked bank account).

Maximum value of transactions per month (calculated as maximum transferred amount per transaction times
the maximum number of transactions per month). There could be an option to set this limit for transfers from
each type of balance (airtime, mobile wallet, linked bank account).
Maximum number of unsuccessful transfer attempts per day. This is required to prevent distributed denial of
service (DDoS) attacks on the platform, i.e. account is blocked until 00:00 the next day after three unsuccessful
transfer attempts. Maximum number of reversal requests per day.
Maximum number of transactions per x period for a certain destination (particular merchant or transfer
recipient).

14 Address management
The ability for a customer to enter multiple addresses that can be validated via external data sources, or when
goods or products are issued to the address. There should be clear identification of the date entered, and all
modifications or validations.

15 Blacklist/whitelist
The ability to identify addresses, names, and customer identification that should be flagged as either acceptable
or to refused.

16 Remittance hub
A service to facilitate international remittance activity, where additional information may be required to support
a normal flow, i.e. enhanced limits, FX (Foreign Exchange Rate) and KYC processes. However, this service will
share the cash in, cash out service, as well as calling the SVA, payment instrument store, payment capability,
and identity management services.

17 Payment gateway

The platform should be able to act as a full payment gateway where necessary, supporting: Integration with
the IPS for onward processing; allowing transaction data to be sent directly from the customer's browser to
the gateway, bypassing the merchant's systems without redirecting the customer away from the website;
forwarding transaction information to the payment processor for authorisation (with support from multiple
schemes, both traditional card-based and alternative wallets); onward validation or rejection to the merchant
of the success of the transaction; clearing and settlement processes for the merchant back end both in real
time and batch modes; clearly assignable liability management to support various authorisation models;
implementing EMV level compliance of transaction handling.

18 Payment switch

The platform could also act as a full payment switch, supporting where necessary: Integration with the IPS
for onward processing; integration with local issuers; integration with local payment gateways and payment
processors; integration with local ATM capability; onward validation of requests for authorisation; onward
validation or rejection to acquire functions of the success of the transaction; clearing and settlement processes
for the issuer and acquirer’s functions both in real time and batch modes; EMV level compliance of transaction
handling.

85