Add IBAN/BIC to autofill options

[anselmh]

There are already a lot of use cases covered in https://html.spec.whatwg.org/multipage/forms.html#autofill but the spec is currently missing autofill options for IBAN/BIC fields. This is useful for payment forms that are no credit card forms.

Filed the issue here as suggested by Anne. https://twitter.com/annevk/status/745248845932683265

[annevk]

I found https://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0097.html and https://bugs.chromium.org/p/chromium/issues/detail?id=165410. One problem is finding a generic thing here that works across countries. Copying @adamroach, @ishermandom, @danbeam.

[anselmh]

Thanks for sharing these references. Worldwide there are still a lot of different codes used in various countries. However, many countries now use solely IBAN/BIC for bank transfers which is the only system being available in most countries world-wide.
So I assume it would make sense to introduce an IBAN/BIC code rather than a universal field description that then accepts any kind of number, which would make it very hard to determine what kind of transfer this indicates.

[prlbr]

What are the security implications? For example, I wonder whether it would be possible to hide IBAN/BIC fields from the user (e.g. by positioning something else over the field) but make the user autofill them anyway, because the user thinks he is justing autofilling his name and e-mail address, for example when writing a comment on a blog.

[annevk]

I don't think those would be different from credit cards, which we already support. Not entirely sure how user agents handle those today.

[anselmh]

It does not differ from credit card security indeed. Note that IBAN/BIC does not have a security code (such as a CVV/CVC for credit cards) but the bank requires the company that want so transfer the money away to have a user-consent for it.

[yatil]

This would be very useful.

[annevk]

cc @whatwg/forms

[nickjshearer]

I am interested in supplementing IBAN with a more generic set of properties that would allow countries that do not support IBANS (notably the USA) to participate. Additionally in some countries that use IBANs it is still common to use a local scheme instead, and it would be nice to support that (for instance, the UK supports IBANs, but typically uses account numbers and sort codes instead).

For example:

Field Name	Meaning	Canonical Format	Canonical Format Example	Control Group
bank-iban	A standardised international bank account number	Valid ISO 13616 IBAN	GB33BUKB20201555555555	Text
bank-account-number	A region specific bank account number	Alpha-numeric, no newlines.	4212345678	Text
bank-identification-code	A region specific bank identification code. For example, an ACH routing number or sort code.	Alpha-numeric, no newlines.	01-02-03	Text

Generally speaking regions that do not use IBANs use an account number and a routing number (also known as a sort code, or bank identification code). Additional thoughts and discussion are welcomed.

[annevk]

@schwering would you all be supportive of adding these features? WebKit is interested in these.

[battre]

I think from Chrome's perspective this makes sense directionally.

There are some questions that come to my mind:

• Should we add an account holder name? For IBAN you typically fill the account holder name and the IBAN together.
• Don't we need to distinguish bank account number types? I think that for ACH routing and wire transfers of a single bank you have different bank-account-numbers. It might be useful to be able to distinguish the account types.

So I was wondering whether we should use the existing tokens mechanism (currently we have shipping and billing) to distinguish between different bank account types. At that point, we might be able to generalize:

bank-account-holder {token}
bank-account-number {token}
bank-identification-code {token}

where {token} could be one of IBAN, SWIFT, ACH, ...

I recently wired money to currencyfair and they provided me three different bank-account-numbers/tokens:

• "SWIFT/BIC"
• "ABA (ACH)"
• "ABA (Wire)"

[hsinyi]

CC @DimiDL

[nickjshearer]

An account holder name makes sense.

Don't we need to distinguish bank account number types? I think that for ACH routing and wire transfers of a single bank you have different bank-account-numbers. It might be useful to be able to distinguish the account types.

Scoping by token seems fine as well. I was not familiar with the token approach when I made my initial suggestion. One challenge would be defining those token values.

[evo42]

IBAN autofill arrived in public Chrome: https://www.linkedin.com/posts/renekapusta_sepainstant-account2account-activity-7111055499982233600-PD4m (currently it's only possible to add / manage one IBAN @ Chrome payment methods UI)

... was quite some time already in chromium: https://source.chromium.org/chromium/chromium/src/+/main:components/autofill/core/browser/iban_manager.cc;bpv=1