Are Multiple Use Cases Supported?

An RTRP system can—and should—support multiple use cases

A Common Core: The Payment Itself

The actual payment order and the settlement of that order among the DFSPs involved can be exactly the same, regardless of use case. This creates the desired efficiencies.

Support for Additional Technical Protocols

Some use cases require additional information exchanges. Merchant and biller payments, for example, may require “request to pay” communications and a standardized approach to generating and scanning QR codes.

Use-Case Specific Pricing, Rules, and Identification

Business rules and scheme pricing may be different by use case. The scheme hub needs to “know” what use case a transaction is, so that the appropriate rules can be applied.

Shared Services

Some markets may find that expanding the scheme’s core services to include other shared capabilities may be the best way to rapidly implement new use cases. Shared merchant or biller directories are one example of this; a shared merchant self-provisioning capability may be another. Shared services decrease the overall economic burden as DFSPs are not required to create redundant capabilities, instead DFSPs share the costs, and capabilities, offered by the scheme.

Enabling Third Party Connection

Specialty aggregators, processors, and other entities operate today in many markets and facilitate use-case specific payments. The role of these entities may change as an L1P-aligned, interoperable system is put in place, but many of their value-added services in the sector may endure. Schemes should think creatively about how to partner with these entities to achieve success in target use cases.

Next Topic in this Section: Is there a Competitive Ecosystem?