SEP-9: remove cvu_number, add cbu_alias

[JakeUrban]

After discussing with our partner, we realized that it is standard practice to use a single field that accepts both CVU & CBU numbers. We also want to add support for CVU & CVU aliases.

[reecexlm]

LGTM.

[theclabs]

I think we should focus the management of bank accounts with an approach of the type: do we really want to add a field for each type of name that exists for bank accounts for each country? the list would be huge. I thought the same when the CLABE field was added.

Would this imply adding each tax identifier type and code for each country as a sep9 field?
RUT_NUMBER for Peru
NIT_NUMBER for Colombia
CUIT_NUMBER for Argentina.
actually tax_id and tax_id_name serve the purpose of avoiding that.

I think the bank_account_number field fulfills the objective of being able to capture the account number.
Maybe we add a bank_account_country_code_name field that has the type and country? AR-CBU, MX-CLABE, GLOBAL-IBAN?
or even something simpler
bank_account_number_name where you can put CBU, CCI, CLABE, etc,

@JakeUrban let me know your comments.

[JakeUrban]

I completely agree that adding new fields for each type of off-chain account is less than ideal. Every time we add a new field, SDKs, test suites, and other tools need to be updated, which is a pain. To be transparent, we added these fields because it was time-sensitive, but we are definitely open to exploring better approaches.

In #1332 I proposed something similar to what you're proposing, where one field was used for all off-chain account identifiers, and instead of having a dedicated field for the type of account, the type was embedded into the field's value.

One challenge with both approaches is that in some countries, it is normal to provide multiple values, as opposed to encoding all the relevant info into a single value. For example, in the US we need to provide a routing and bank account number. Others require an additional value for the bank branch.

So whatever name we chose, I think it would need to be possible for this "type" field to correspond to a set of fields, not just one. There are really two solutions to this:

• Use an object, where the type attribute corresponds to different object schemas
  • This is tough to make work because SEP-9 isn't designed to support nested fields, there are plenty of other places (SEP-6, SEP-12, SEP-24) that assume KYC info can be communicated using simple key-value pairs
• Define a string format for each set of fields that correspond to each type
  • This could be more easily integrated into the existing protocol's design