Consider allowing Alice to send payment details during RFQ or Order step

[jiyoonie9]

Using an IRL example, sending in all payment details in the RFQ step would be analogous to:

1. Offering: At a farmer's market, I look at various cheese being offered at a stand. It says she sells goat cheese and she accepts US debit cards.
2. RFQ: I ask how much it would be to buy 1/2lb goat cheese using a debit card, but while asking, I start whispering my US debit card number to the cheesemaker (??)
3. Quote: Cheesemaker tells me how much 1/2lb goat cheese is (10 USD), and shows me her phone that lets me tap my card to pay
4. Order: I tap the phone and pay
5. OrderStatus: Cheesemaker cuts and wraps the cheese
6. Close: I walk away with the cheese

My qualm is with step 2. Why do I need to provide my debit card details during the RFQ step? It would be quite weird to do this in IRL, is there something would make this not weird / required in a tbdex exchange?

A scenario that would make more sense to me is that I'd send over my debit card details during the Order step, but currently Order is an empty struct.

[frankhinek]

For many payin methods, a PFI will likely not include requiredPaymentDetails in the Offering such that sensitive/private payment information (debit card no., postal code, bank account no. etc.) are not required to submit an RFQ. Instead the PFI's Quote response will include a payin link that can securely collect payment details. That being said, there may be some payout methods where payment details are collected (e.g., paying out to a local bank account).

To zoom out for a minute, it is common and beneficial to require basic payment information (e.g., the type of payin and payout methods the sender intends to use) at the RFQ stage to provide more accurate quotes, as fees and exchange rates may vary depending on the payment method. However, typically money transfer systems do not require detailed payment information, such as debit card numbers or bank account details, in an RFQ.

The RFQ/Quote response stage is usually focused on providing the sender with information about the exchange rate, fees, and the amount the recipient will receive, rather than collecting sensitive payment information. Reasons can include:

• Security: Collecting sensitive payment information early in the process could pose security risks if the sender decides not to proceed with the transaction or if the quote expires.

• Privacy: Requesting detailed payment information before the sender has agreed to the terms of the transaction could be seen as an invasion of privacy.

It seems reasonable to collect sensitive payment details later in the process during the "Order" stage, after the sender has agreed to the terms of the transaction and is ready to fund the transfer.

[KendallWeihe]

In favor of "It seems reasonable..." though I would add, to support the broad array of potential use cases the protocol probably has to support the transmission of PII at both the RFQ or the Order stage. Right? Because I can think of concrete use cases in the realm of credit transactions wherein, in order for a Quote to be issued, PII must have already been submitted. Perhaps we can simplify by deeming any such use case as out-of-scope.

[michaelneale]

I have thought for some time as to why things were in RFQs and why order contained all the information and why Order was really an ACK. In the original paper there is a back and forth with "bids" and "asks" and then a final bid which is "acked", so I think, but am not sure, maybe that was the origin of why Order is functionally an ack message.

The only possibly vaguely functional reason as to why to include it in RFQ I could think was to know enough to decide if a quote can even be provided (checking denylists etc) and perhaps some finer grained decisioning around PII (but I don't know what that would be in the case of a payment or remittance, for insurance for example of course, but that isn't really a case that is relevant!).

Also, having tried a few things just yesterday, from what I can tell all of them quote before having all that information, but to get a real quote (for example with OFX) I was onboarded with them (so they had some PII of mine, and knew I would be receiving a remittance by an AUD bank account) so it isn't quite as clear to me (and perhaps is why the paper had that dance of BID/ASK and then an ack).

Having said that, the KYC process would take care of the onboarding-ability with a PFI, so I conclude like @frankhinek that if we could, perhaps putting data in the order instead of the RFQ may make more sense in the general case.

EDIT: I just realised KYC happens when you ADD a PFI, so at that point, does that mean the PFI is showing offers potentially specific to you? (the spec doesn't say that, as offering is an endpoint anyone can access, like a shopfront window) but providers I have worked with, the offers are fine tuned to me once I am onboarded.

[corcillo]

Agree with that it seems most reasonable to have the actual instrument info (i.e. debit card number) on the Order message as it the customer is accepting the quote. Im forgetting if there was a reason it was placed on the rfq, but it might be because thus far weve only built on ramp proof of concepts w a payment link, not a literal debit card, thus attaching debit card info on rfq might not have been given a second look (or I might just forget why its there lol).

I'm pretty sure for the on ramp via payment link, the payment link is returned in the quote in response to the rfq, and to confirm execution, the customer must go to the link and submit payment details there instead of actually sending an Order message. In this case, Order messages to confirm execution is redundant and was not actually used in the poc.

[corcillo]

This does come up for offramps though, we do currently need to provide external bank acct info on rfq (based on the tbdex spec), which i also think would be better suited on order.

[mistermoe]

Totally agree @jiyoontbd and actually have exactly what you brought up written in a list for myself to tackle regarding spec text changes:

how i was thinking about proposing this was the following:

• the ability to provide payment details in an order would be an added feature, it wouldn't replace submitting payment details in an rfq.
• both would be optional.
• if payment details are expected in the RFQ, the required payment details would be expressed in the offering (as it exists today).
• If payment details are expected in the order, the required payment details would be expressed in the quote.

technically this allows a PFI to choose amongst the following:

1. ask for all payment details at time of rfq
2. ask for all payment details at time of order
3. ask for some details at time of rfq and some details at time of order

[mistermoe]

I have thought for some time as to why things were in RFQs and why order contained all the information and why Order was really an ACK. In the original paper there is a back and forth with "bids" and "asks" and then a final bid which is "acked", so I think, but am not sure, maybe that was the origin of why Order is functionally an ack message.

The only possibly vaguely functional reason as to why to include it in RFQ I could think was to know enough to decide if a quote can even be provided (checking denylists etc) and perhaps some finer grained decisioning around PII (but I don't know what that would be in the case of a payment or remittance, for insurance for example of course, but that isn't really a case that is relevant!).

Also, having tried a few things just yesterday, from what I can tell all of them quote before having all that information, but to get a real quote (for example with OFX) I was onboarded with them (so they had some PII of mine, and knew I would be receiving a remittance by an AUD bank account) so it isn't quite as clear to me (and perhaps is why the paper had that dance of BID/ASK and then an ack).

Having said that, the KYC process would take care of the onboarding-ability with a PFI, so I conclude like @frankhinek that if we could, perhaps putting data in the order instead of the RFQ may make more sense in the general case.

EDIT: I just realised KYC happens when you ADD a PFI, so at that point, does that mean the PFI is showing offers potentially specific to you? (the spec doesn't say that, as offering is an endpoint anyone can access, like a shopfront window) but providers I have worked with, the offers are fine tuned to me once I am onboarded.

aye @michaelneale you got it. the reason all information was requested as part of the RFQ was because at that time we were operating under the assumption that KYC would happen implicitly using the details provided within an RFQ and we didn't want to:

• return a quote until we knew for certain we were in the clear to provide a financial service from a regulatory perspective
• didn't want to ask for a bunch of info you have to hunt down after receiving a quote with the clock ticking. wanted to prevent the user experience of sweating bullets trying to race the clock to fill out an 18 field form half of which requires you to reach out to some other person and ask them for info they don't readily have on hand or memorized

the 2nd point still being possible is why i think adding the ability to request payment details at order time vs. replacing the ability to request details at rfq time makes sense.

[michaelneale]

yeah - sounds reasonable. @mistermoe now KYC happens at PFI onboarding, does that also change offerings to be different after KYC vs anon offers via offers endpoint?