Should region data be added to Offerings?

[frankhinek]

How does a consumer web/mobile App determine which Offerings are valid to display to a user based on the data contained within the offerings returned by 1 or more PFIs?

An Offering's payin and payout fields contain a currencyCode but you can't always infer the country based solely on this information:

• Multiple countries in Africa share the same currency:
  • 8 use the West African CFA franc (XOF)
  • 6 use the Central African CFA franc (XAF)
  • 4 countries accept the South African Rand (ZAR)
• In addition to the USA, at least 8 countries accept USD as legal tender (Panama, Ecuador, El Salvador, Marshall Islands, etc.).

The issue being highlighted is that a given PFI may only be about payout a particular currency in certain countries. How could an Offering indicate this so that the app can filter out offerings that don't support a given (sender, payin method, payout method) combination?

For example:

• PFI A has an offering that includes a USD payout method, but the PFI can only legally operate in Panama (but not Ecuador). If the user is attempting to send to a recipient in Ecuador, the app shouldn't display this offering from PFI A.
• PFI B can legally operate and payout XAF in Gabon, Chad, and Cameroon. If the user is attempting to send to a recipient in Central African Republic, Republic of the Congo, or Equatorial Guinea, the app shouldn't display this offering from PFI B.

It seems like the tbDEX protocol should provide a consistent way to determine which country(ies) a payin or payout method is supported in to improve the user experience. In other words, provide Apps a consistent method of filtering Offerings that don't make sense given what the end user is attempting to accomplish

Supported countries could be included in the requiredPaymentDetails of the offering -- and then submitted in an RFQ's privateData.paymentDetails, but I'm still wondering if we would want to change anything about the protocol to encourage inclusion of country data if we want to support filtering Offerings based on the location/residence of the sender/recipient or the payin/payout method selected.

Suggestion

It seems beneficial to have region/country information at the PayinMethod and PayoutMethod level (and not at the top-level offer) since a particular PFI may operate in 10 countries, but still can't serve a particular RFQ if the combination of (sender, payin method, payout method) is not supported.

[michaelneale]

in cases where the user has accumulated VCs which can be re-used across PFIs - and has preferences, then sorted offerings may make sense and be much easier to do. In fact, given most of the work from the users PoV would be IDV, right, then that would drive perhaps some behavior? (in cases of a blank slate - not sure, was more thinking the re-entrant case). In some ways the blank slate is more urgent/important as that would act as the obstacle.

[nburgess48]

I think what you're saying makes sense Frank, and would enable a better UX for wallet users. Since otherwise a Sender may go through a PFI's entire flow only to be rejected after KCC application (un-supported Sender country) or after providing the Recipient's payout information (un-supported Receiver country)

If we go this approach though, would we need to move the relevant PD(s) into the PayinMethods to make sure the Sender gets pushed to the right KCC issuance/prez flows given their region?

[michaelneale]

thinking a bit more about this based on experiences I have had with remittance providers as well:

• Typically when I pick a provider I would look up front if they serve the destinations I need - and there is some assumption (on my part) that they would support some suitable range in the destination country that the recipient could use
• The biggest constraint is in PFI selection first: what is available for me to "on ramp" to.
• once I am on boarded (as a sender) then I would select offerings based on tradeoffs of time/fees/spread and knowing how I can get it to the recipient).

Scenario 1) USD to AUD: (self remittance)

• I pick a FX provider which has a USA bank that can receive a domestic xfer, and payout is AU bank account
• In that provider I then choose how I would want to get the funds (or send the funds) - usually around how fast and lock in a rate and "book" the transfer
• USD funds are disbursed to US side bank account
• Funds are converted and disbursed in AUD from local bank

Scenario 2) AUD to USD: I need to pay back someone in USD to their cashtag

• I find a local remittance provider that will have me as a customer and can do USD
• I check if their USD side can pay out to cashtag addresses (so far none can so I was sad)
• I fund it from local bank account

Not sure if any of this informs what sort of regional information; but to me it seems heavily around selection of the PFI more so than selection of offering (but then knowing what offerings they have can be done before I have added them). So I really want to know can it accomodate first me as a customer, and secondly payin/payout pairs of currencies and mediums that I need (payout is usually determined by whom I owe money to, payin is fairly static).

Any help?

[mistermoe]

i've been thinking about this using the following concrete examples:

1. USD -> USDC on-ramp
2. USDC -> USD to U.S. bank account off-ramp
3. USDC -> USD to PK bank account off-ramp (legitimately possible using Roshan Digital Accounts)
4. USD -> MXN to MX bank account (traditional remittance)
5. USD -> MXN to Swiss bank account (traditional remittance)

Examples 1-3

Examples 1-3 are effectively self to self. by that i mean there is no recipient which can also be technically thought of as: the sender is the recipient. in these scenarios, where you're on or off-ramping from or to has a direct correlation to the KYC requirements that PFI bears in order to provide a financial service in that respective region. For example, a USDC -> USD to PK bank account off-ramp would necessitate PK KYC.

Given this, i think region as a top-level property of an offering makes an individual offering simpler to not only filter but also represent required claims for. The requiredClaims for USDC -> USD (pakistan) will certainly be different than USDC -> USD (usa)

Examples 4-5

These traditional remittance offerings is where i can see each payment method having a region being useful. If i'm looking to remit MXN to be received in a Swiss bank account (actually don't know if this is possible), and a PFI happens to offer MXN remittances to Mexico and Switzerland, presumably the offering would look like:

{
  "payin": {
    "currency": "USD"
    "methods": [{
      "kind": "PAYMENT_LINK"
    }]
  },
  "payout": {
    "currency": "MXN",
    "methods": [{
      "kind": "SPEI",
      "region": "MX"
    }, {
      "kind": "BANK_ACCOUNT",
      "region": "CH"
    }]
  },
}

Practical Considerations

I didn't see a region selector when looking at the websites of well-known traditional remittance providers. here's wise's homepage as an example:

notice i can select my own reigion up at the top in the status bar but the remittance form only has currencies. not currency + region.

my only personal experience holding multiple currencies in a single bank account was using Roshan Accounts which make it appear as if i'm holding (and can send) USD directly to Pakistan. while advertised as such, the banking infrastructure under the hood is a Nostro Account. turns out the USD is actually held in a U.S. correspondent bank. That said, Nostro accounts are often internal details and used for internal forex. i haven't really seen examples of "i need to send actual MXN to be received as MXN in Switzerland" as a prevalent feature.

[nburgess48]

Another data point: Interestingly Wise does let users hold multiple currencies and receive money into those accounts. But similar to what Moe describes above the accounts they create on your behalf to facilitate these payments are all "local".

So from the perspective of a PFI collecting requiredPaymentDetails for a Remittance: these accounts would look no different from a US-based account holding USD. Or an EU-based account holding Euros. (the region the account is located in matches the currency).

I imagine then the only reason a PFI might reject these Remittances due to Recipient region would be due to the recipient's address (assuming the PFI requires collection of that field) falling outside a region they support (not necessarily due to information gleaned from the requiredPaymentDetails.

That said, I'm not sure if this practice holds true across the board. But it's one additional data point nonetheless

[michaelneale]

@nburgess48 yeah good point - I have used it like that too, but all in wise.

[jiyoontbd]

notes out of tbdex discussion

• region means thisOfferingCanSupportCustomersOriginatingIn - consider coming up with a clearer name that meets this definition
• make region top level required, and payin.region and payout.region optional