Message Formats: Rules determine data requirements and message formats; some data requirements may be specific to certain transaction types. Schemes may have their own proprietary message formats, or may rely on international standards such as ISO20022. An important aspect of the message format is identifying the transaction type: this is particularly important if specific rules will apply only to certain transactions (Example: NACHA International ACH Transactions or IATs).

Participant Identification: Rules may specify participant identification and the means by which participants register for unique scheme ID’s which are used in transactions.

End User Identification: Normally, a payment scheme relies on the sending participant to provide the receiving participant’s scheme ID and the receiving end-party’s account number (or other identifier). The scheme rules specify this in the data requirements for messages. In some schemes, an additional step is provided as an option, so that a sending end-party can send with only a phone number, or some other token of identification of the receiving party. In these cases, the scheme (or a processor chosen by the scheme) keeps a directory of phone numbers/tokens and their associated participant ID/end-user account number. This service also needs to provide for the ability of an end-user to register their phone number/token with the directory. The operating rules need to cover the processes involved in this.

Data Security: Rules establish requirements and processes for safeguarding end-user payment data. These may be scheme-specific standards, or may call on international standards by reference.

Device and Software Certification: Rules establish requirements and processes for approving and certifying devices, software, or processors which connect to the scheme in some way. The requirement for certification can be an expense burden on participants, their vendors and the scheme itself. There may be debate over the use of legacy formats vs. emerging global standards. The use of global standards like those developed by ISO, both for message formatting and for data requirements, is highly desirable to enable easy integration of payments with providers and value added solutions. The scheme may handle the certification processes itself, or may outsource this to other providers.

Certification of Third Parties: Scheme rules may require that processors, operators, or other third parties participating in the system be certified to meet standards set by the scheme.

Quality Standards: A scheme may require participants to provide data to support that certain operating standards have been met. This might include, for example, system availability, transaction timing or completion rates. A scheme may also require that participants report on levels of fraud claimed by end users: this may be particularly relevant for certain use cases, such as merchant payments.

The Financial Inclusion Perspective

The use of global standards will make it easier for new participants to join payment system schemes where they can build value-added applications. Inclusion of a broader set of participants should increase innovation and price competition and benefit the poor. The ability to work with data requirements that support easy registration of end-users phone numbers that can be mapped to accounts also helps simplify the transaction process for the poor.