2017-12-17

New RFC? IBAN URI

I am wondering if there is already an RFC for this, and if not if one is needed.

The idea is a URI / URL that identifies a bank account, and maybe a bit more relating to a specific payment...

What I would suggest is something like

 iban:GB89SRLG60837172100359

Which would identify a bank account. Useful to share as a bank reference to set up new payee, etc.

I suspect it needs some extra, including a payment reference and amount, eg.

 iban:GB89SRLG60837172100359/GBP1.00?Some+Dosh

I am sure an RFC can be made for this. With the number of payment apps and new style bank accounts, this would be a useful feature for on-line banking payments. Avoiding retyping of bank details is important and useful.

I'd hope that on a phone it would say "Pay this from Monzo / Starling / Barclays / Lloyds" as a choice for the banking apps I have.

Is that a good idea?

Update:

It almost certainly needs, in addition to the IBAN itself, a number of optional tagged fields such as payee name, reference, amount, or some such.

Payment it should be pay:

P.S. Someone suggested EPC069-12 which is interesting, but to be honest a simple URL coded in a QR code sounds way more sensible.

Update:

If someone has experience making RFCs, let me know. I made a start (here).

14 comments:

  1. Switzerland has this, more or less. Here's a payin slip from a sample invoice:

    http://unappel.ch/public/080902-layout-red-slip/index_files/image001.png

    The big number in the bottom right contains the amount, destination Post Office account, and the payee's reference number (the big number middle right). You can usually scan or enter this and your ebanking system will cue up the appropriate form.

    I _think_ this only works in you have a Post Office banking account (which most people do). There may be an IBAN version, but I can't find an example.

    ReplyDelete
  2. Whilst this seems like a great idea, I think you'll find that the international banking system is more akin to a bunch of ugly hacks rather than a coherent interface. Thins to watch out for include banks and accounts that you cannot access directly (you need to go through bank A to reach bank B) and systems that insist on redundant info (account name, account number, sort code, bank name and address and more), so that they can confirm that they can cross-check one against the other.

    ReplyDelete
    Replies
    1. Indeed, but I am thinking mainly for use with banking apps, where you can simply send money to an IBAN (which, for GB, has sort code and account name in it).

      Delete
  3. Replies
    1. Quite, a simple QR code link to URL link to banking app to pay for something.

      Delete
  4. If this is a URN, it'd be:

    urn:iban:GB89SRLG60837172100359

    Or, experimentally:

    urn:x-iban:GB89SRLG60837172100359

    https://en.wikipedia.org/wiki/Uniform_Resource_Name

    ReplyDelete
    Replies
    1. I am thinking a specific action taking URL prefix, not just a namespace URN.

      Delete
  5. Is it worth explicitly including that it's an IBAN, so that other destinations (e.g. BACS, paym, monzo.me) could be included?

    ReplyDelete
    Replies
    1. Well, IBAN covers them all doesn't it.

      Delete
    2. I think a generic bank schema with a type field is of more use than a simple IBAN, since it allows for encoding many different payment schemes, which would be helpful, could even encode more than one scheme into a admittedly long string

      Delete
    3. Are there schemes that are not encompassed by IBAN though - even Monzo to Monzo could use IBAN where Monzo simply recognise their bank in the IBAN.

      Delete
    4. IBAN wouldn't cover crypto payments however (worthy of inclusion if you're thinking of a generic payment scheme)

      https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki

      Delete
    5. You get into fun, however, with banks that don't automatically issue an IBAN to their customers. Notably, they are optional in the US, Canada, New Zealand and Australia, and only issued to customers who need to make international transfers.

      There is no standard format for all possible destinations outside SEPA :(

      Delete
  6. It should also include the ability to pass the PSD2 SCA one time code (dynamic linking) for extra props and useful to people wrestling with how to pass that code between systems.

    ReplyDelete