Determine the in/exclusion of "on-us" transactions in Mojaloop. Also discuss the effort required to make it available, as currently, such transactions are rejected.
Artifacts:
[ ] Artifact to consider [@Contributor]
Decision(s):
[x] All agree in principle to allow on-us transactions
[ ] Investigate Source Base to determine the effort required to make allowance for this
[x] Request contribution to the Section at the bottom for expansion of edge cases and questions
[ ] Ensure this topic is added in some form to the Agenda at the PI-7 Convening
Follow-up:
[ ] Alternative actions
Dependencies:
[ ] If Applicable
Accountability:
Owner:
Notes:
Miller's comments:
Canada’s Interac system, arguably serving more transactions between fewer people, requires and enables on-us transactions. Banks like this as it saves them the headache of different processes for on- and off-us transactions. And they can’t compete on cost with Interac, since on-us transactions are no cost.
This avoids what the card industry calls “sort-at-source” which is a questionable practice whereby, e.g., Bank of America would notice that a transaction acquired by one of their merchants was from a consumer within their issuing BIN range. So BofA would argue, why send this to Visa? We’ll just process locally and keep the full interchange to ourselves. Visa specifically prohibits this for economic reasons, so banks and acquirers don’t invest in sort-at-source. And Interac also prohibits sort-at-source, but incentivizes banks.
While it may seem technically odd to process transactions this way, the benefits to regulators and banks is high. And since the cost to process transactions is indirectly proportional to transaction processing volume, including on-us transactions through the switch is a long lever to reduce cost.
We can work on the non-technical analysis. Let’s ensure the system does not arbitrarily prevent this and work out a validation strategy.
Be cautious about corner cases… e.g. offsetting can be a liquidity efficiency tool, but handling net-zero settlement should be designed carefully.
Do we require ALS dip for on-us? (YES! We don’t know who holds the payee’s default association for the given payee ID.)
Does switch require explicit marking of prepared on-us txs or are they implied? (implied, it simplifies DFSP processes, and since switch must check anyway)
Does a DFSP flag on-us transactions during quotation request? Is there a standard way, or is this just left as proprietary extension data?
Do we reserve send-side settlement liquidity for on-us? (yes, but let’s discuss this with BankServ, BoT, and Glenbrook).
Do we enter cleared on-us txs (net zero) into a settlement batch? (yes, notice of settlement is the reconciliation source, even for net-zero transactions).
Do we accommodate separate wholesale fees for on-us? (yes)
How is cross-currency considered for on-us? (it’s cross-ledger, domestic fx, and so processed not differently than any other domestic fx transaction, send-side liquidity is reserved on both legs)
Request:
Determine the in/exclusion of "on-us" transactions in Mojaloop. Also discuss the effort required to make it available, as currently, such transactions are rejected.
Artifacts:
Decision(s):
Follow-up:
Dependencies:
Accountability:
Notes:
Miller's comments: Canada’s Interac system, arguably serving more transactions between fewer people, requires and enables on-us transactions. Banks like this as it saves them the headache of different processes for on- and off-us transactions. And they can’t compete on cost with Interac, since on-us transactions are no cost.
This avoids what the card industry calls “sort-at-source” which is a questionable practice whereby, e.g., Bank of America would notice that a transaction acquired by one of their merchants was from a consumer within their issuing BIN range. So BofA would argue, why send this to Visa? We’ll just process locally and keep the full interchange to ourselves. Visa specifically prohibits this for economic reasons, so banks and acquirers don’t invest in sort-at-source. And Interac also prohibits sort-at-source, but incentivizes banks.
While it may seem technically odd to process transactions this way, the benefits to regulators and banks is high. And since the cost to process transactions is indirectly proportional to transaction processing volume, including on-us transactions through the switch is a long lever to reduce cost.
We can work on the non-technical analysis. Let’s ensure the system does not arbitrarily prevent this and work out a validation strategy.
Be cautious about corner cases… e.g. offsetting can be a liquidity efficiency tool, but handling net-zero settlement should be designed carefully.
Do we require ALS dip for on-us? (YES! We don’t know who holds the payee’s default association for the given payee ID.)
Does switch require explicit marking of prepared on-us txs or are they implied? (implied, it simplifies DFSP processes, and since switch must check anyway)
Does a DFSP flag on-us transactions during quotation request? Is there a standard way, or is this just left as proprietary extension data?
Do we reserve send-side settlement liquidity for on-us? (yes, but let’s discuss this with BankServ, BoT, and Glenbrook).
Do we enter cleared on-us txs (net zero) into a settlement batch? (yes, notice of settlement is the reconciliation source, even for net-zero transactions).
Do we accommodate separate wholesale fees for on-us? (yes)
How is cross-currency considered for on-us? (it’s cross-ledger, domestic fx, and so processed not differently than any other domestic fx transaction, send-side liquidity is reserved on both legs)