Closed paultiplady closed 5 years ago
@paultiplady these are great points.
The fact that the required fields are dependent on the country makes it impractical to define all the possible fields in a global SEP like SEP-9.
This kind of situation, where an anchor needs to communicate which kinds of bank number types it supports for deposits and withdrawals, should be handled by SEP-6. An anchor can broadcast its capabilities with /info
, and the specific kind of bank number or deposit / withdrawal method for a particular transaction can be specified by the client passing type
to deposit or withdrawal.
That should handle open questions 1 & 2.
As far as per-country regulatory information, the goal of SEP-9 is to cover the ~80% of most common use cases. We can add fields as they're needed for more major use cases. Any fields that are more rare should be handled with an interactive flow provided by the anchor instead.
As far as changing regulatory requirements, SEP-9 aims to allow a wallet or other client app to collect information from a user once, and then reuse that information multiple times as the user performs KYC with different anchors. If we add dynamic fields, there's no way to reuse them. A wallet can't be sure that a dynamic field called "cpf_code" for anchor A is the same as for anchor B, even if the names match. That's why SEP-9 is hard coded. That said, as regulations change, SEP-9 should be updated to include new fields.
Dynamic fields should just be handled by one-off KYC flows provided by anchors, since they can't be re-used by the wallet with other anchors.
Please feel free to suggest a list of fields that would be useful for you (patronymic name, CPF code, etc...) and we'll merge those in to get you going.
Thanks, that clarification is useful -- so for countries with regulatory requirements the solution is just to defer to the interactive flow in the anchor's UI. That actually works fine, in my experience the extra regulatory fields only apply to 10-20 countries in the world, definitely in the long tail of payment volume.
I'm wondering though, how would you expect the anchor to communicate e.g. ACH vs. wire for a US payment in the 2. Customer information needed (non-interactive)
flow? I don't see how that flow can work at all, given that bank_number
is fundamentally ambiguous. It seems that the client would need to parse the /info
and see that it says
{
"withdraw": {
"USD": {
"types": {
"bank_account": {
"fields": {
...
"dest_extra": { "description": "your routing number" },
...
Instead of "your SWIFT number"
. If those fields are freeform text, it's going to be difficult to reliably differentiate between the two.
If we define "bank_number" to mean "bank number in the national banking system" that will cover most countries unambiguously (though e.g. India does have multiple national bank codes), and extra fields for "swift_code" and "iban" would cover the international bank identifiers used in most countries.
I'm not currently blocked on this by the way -- my use-case is USD-specific for now. Just raising as I went through the exercise of thinking through how I'd map my existing international payments onto this flow.
Good questions @paultiplady.
This PR clarifies an anchor communicating ACH vs. wire for a deposit.
Here are the steps:
ACH
and wire
) for example in the deposit.USD
section of the /info
responseACH
or wire
for their deposittype=ACH
(or whatever the user chose) to /deposit
/deposit
responseThat doesn't involve SEP-9, which is more for KYC / AML. bank_number
is included there since it can be a piece of information about a person that's used for KYC, but it's not necessarily the same as the account used for deposit / withdrawal.
That said, I'll update SEP-9 to improve the definition of bank_number
like you suggest. Thanks so much for your thoughts!
PR: #163
Closed by #163. Thanks @paultiplady!
Moving discussion from https://github.com/stellar/stellar-protocol/pull/136#issuecomment-414441903:
In SEP-9, we have the fields:
I'm a little concerned that the
bank_number
field won't be workable for global payments -- for example, in many countries, there are a number of different "bank numbers"; e.g. to pay someone in India, it might be:SWIFT (if you're sending them a wire) IFSC INRN
Or a less esoteric example, to get to the UK it might be:
SWIFT Sort code IBAN (this actually includes bank number and account number)
Additionally, the anchor might only be able to process a subset of the bank number types, e.g. only supporting wire to the UK, even though a local would naturally provide "sort code" in this case.
The international payments API that my system uses is (unfortunately) quite complex, and the required fields are dependent on what country the beneficiary is located in. (This is quite standard for international payment rails, in my experience).
Not to mention that certain countries require additional regulatory information such as patronymic name in Russia (in addition to first/last), or CPF codes in Brazil. (An even bigger can of worms).
In summary, I think there are a few open questions here:
bank_number
types) an anchor supports?bank_number
type is being sent?CC @tomquisel