Transaction Processing

Timelines

Rules establish the required timelines for submitting transactions, posting transactions to end-users accounts (may vary by transaction type), submitting exception transactions, etc. If participants use a third party (non-scheme) operator there may be additional requirements in the operating circulars of the operator. The industry is undergoing a shift from batch to real-time processing of transactions: rules in a real-time context may be written in terms of amount of time lapsed from one event (for example, a consumer issuing a payment order) to the next (for example, delivering the transaction to the switch). There may be law or regulation which determines when a provider can/must post a transaction to a consumer or business account.

Returns and Exceptions

Every system needs to account for transactions to be returned. Rules define allowable reasons for return and the timeline and message formatting for the return (message formats will typically include return reason codes). Allowable reasons will include:

• an unrecognized recipient account number
• an erroneous message (wrong formatting, missing data, etc.)
• if the scheme is using some type of a directory (see section ‘Standards’ – ‘End User Identification’), there will need to be highly specific rules about what happens if a directory entry is wrong, has changed, etc.

There may be additional exception circumstances identified which need to be addressed in the operating rules. Such situations may include when one participant is offline, when a participant’s settlement account does not enable a transaction to be processed, etc. Exceptions that may be considered ‘local’ (that is, between the end-party and their participant, such as a participants service being unavailable) would not be addressed in the scheme rules- these would instead be addressed in the contracts between the end-parties and their provider/participant.
Rules also need to take into account when a receiving participant may refuse a transaction when directed to an account which is open at that institution: for example, a transaction which is deemed problematic from a fraud or risk management perspective on the receiving side. If the system allows this, there needs to be a rule requiring the receiving institution to make notice of the refusal available immediately to the sending institution.

Dispute Resolution

Finally, rules may or may not specify how an end-party can dispute a transaction with their participant, such as a claim that a payment transaction was not authorized by the account holder. If operating rules cover this, it has the advantage of creating a common set of standards across participants. These rules may specify how disputes can be presented and the timelines for this. National law or regulation may also apply here.

The Financial Inclusion Perspective

For the digital system to be a viable alternative to cash, it must be robust, meaning available to users as needed. The operating rules may need to provide clarity on how to handle processing given the current circumstances and realities of the developing world.