Interoperability is a governance decision before it is an API

Provider A can send the correct payment message to Provider B. The account number passes validation, both systems return success and the customer sees a debit. Several hours later, the recipient says no usable money arrived. The API worked. Interoperability did not.

Payment systems connect legal obligations and operating processes as well as software. The World Bank's 2026 work on instant payments in Africa identifies governance, participation and consumer protection among the conditions for scale. AfricaNenda treats reliability and recourse as part of inclusion. The transaction that goes wrong reveals why.

Identity before routing

A sender needs a reliable way to specify the recipient. Account numbers, wallet numbers, phone aliases and merchant codes can overlap across providers. An alias directory may resolve a phone number to an account, but someone must decide who can register, how ownership is checked and what happens when a number changes hands.

Confirmation of payee can reduce mistakes by showing a recipient name before approval. It also creates privacy and liability questions. How much of the name appears? Can fraudsters query the directory? Is a close match enough? If the provider displays the wrong name, who pays for a mistaken transfer?

Write those decisions as scheme rules. An API field named recipient_name cannot decide their legal effect.

A provider needs an update process for closed accounts and reassigned aliases. Stale directory records turn a convenience feature into a loss channel. Measure failed lookups, mismatches and correction time.

The message crosses a risk boundary

After the customer approves, the sending provider checks balance, limits and fraud signals. The receiving provider checks whether the destination can accept the payment. Each institution sees different data.

If one provider flags a transfer after the other has credited it, the scheme needs a response. Can the credit be frozen? Is consent required to reverse it? Does transaction finality block reversal while allowing a separate recovery claim? The answer depends on law and scheme design.

Message standards help both sides describe the event consistently. They do not make risk appetites identical. A small wallet and a large bank may set different limits. Interoperability should permit lawful differences while giving the sender a clear result before money leaves.

Timeouts deserve explicit treatment. A provider can receive no response because the request failed, the response failed or the other side processed the payment and went offline. Retrying without a unique transaction identifier can duplicate the transfer. Marking every timeout as failure can encourage the customer to send again.

Settlement sits behind the customer message

Customer interfaces can update before institutions exchange final funds. The scheme defines whether settlement occurs transaction by transaction, in batches or through prefunded positions. It also defines when the receiving institution can treat funds as final.

A participant with insufficient liquidity may be unable to send while still receiving. Queues can preserve transactions or create uncertainty. The operator should expose position alerts to participants and give customers an accurate status.

Cross-border connections add currency conversion and multiple settlement assets. A fast message does not create liquidity in the destination currency. Someone quotes the rate, holds inventory and accepts price movement until settlement. Governance decides who that is.

Reconciliation closes the day. Both participants and the scheme operator need matching records of accepted, rejected, reversed and pending transactions. A customer support team cannot resolve a missing payment if internal systems use different identifiers.

The complaint travels another route

The sender contacts the provider it knows. That provider may need evidence from the recipient's institution, the switch and an alias directory. A scheme with no shared case process makes the customer carry messages among companies.

Define a single case identifier, evidence fields, response deadlines and escalation path. Allocate responsibility for customer communication even while institutions dispute the loss. Silence is not neutral when rent or stock money is missing.

Fraud cases differ from technical errors. A customer who authorised a transfer after deception presents another question from a duplicate debit or misrouted alias. Rules should classify the event before applying a remedy.

Publish aggregate outcomes: complaint volume, resolution time, disputed value, recovery and cases past deadline. Do not publish details that expose controls or customers. The purpose is to show whether interoperability extends to repair.

Commercial rules can break a technical connection

Providers pay scheme, settlement and connectivity charges. They may also pay each other. If the price of receiving or cashing out exceeds the revenue available, a participant can restrict the service despite successful integration.

Service levels need remedies. An institution that repeatedly fails can harm every connected provider. The scheme operator requires monitoring, an improvement process and the ability to limit or suspend a participant. That power needs due process because suspension also cuts customers off.

Change management matters after launch. A new message version, fraud control or limit affects many systems at once. Set notice periods, test windows, backward compatibility and emergency procedures. Smaller participants need enough time to implement without freezing the network's security response.

Draw governance on the system diagram

A useful architecture diagram labels more than servers. Put the legal operator over the switch, the regulator beside participation, the settlement institution under the money movement and the complaint owner beside the customer. Mark who can change each rule.

Then walk one failed payment across it. At every handoff ask who has the record, who can act, how long they have and who carries the money in the meantime. Gaps in that walk are interoperability defects even if every endpoint returns a valid response.

The API is necessary. The rulebook is what lets two institutions trust the result when the happy path ends.

Sources

• World Bank, March 2026: Scaling Instant Payments in Africa
• AfricaNenda Foundation, 2026: Pan-African trade and inclusive instant payments focus note