Internet Engineering Task Force A. Kennard, Ed. Internet-Draft Andrews & Arnold Ltd Intended status: Informational June 12, 2020 Expires: December 14, 2020 A URI for making banking payments quitable for QR 2D encoding kennard-draft-pay-uri-02 Abstract Many web browsers and similar applications are included in devices (such as mobile phones) that are themslves capable of making banking transfers. This RFC proposes a standardised URI which can be used within web pages, emails, QR codes, and so on, allowing a simple way for recipient bank details and related information to be used by the device to instruct a payment to be made. This avoids the need to manually enter account information and hence avoid typing errors which may lead to failed payments, or worse, payments sent to the wrong account. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 14, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Kennard Expires December 14, 2020 [Page 1] Internet-Draft Bank payment URI June 2020 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. URI format . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. National payments . . . . . . . . . . . . . . . . . . . . . . 4 4. Character set . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Minimum URI . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Defined parameters . . . . . . . . . . . . . . . . . . . . . 4 6.1. amount . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. payee . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3. reference . . . . . . . . . . . . . . . . . . . . . . . . 6 7. QR code . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Financial institutions are increasingly providing apps that can be installed on mobile phones and other devices allowing their customers to access bank accounts and make near instant payments to payees. At present, these apps require account details to be manually entered in to the device by the user in order to set up a new payee and then make a payment. This can easily lead to errors being made entering the details manually. The result may be a failed payment or a payment that goes to the wrong account which may be difficult or impossible to reverse. Another common issue is the use of a payment reference. It is easy for the payer to enter this incorrectly, or not consider it important in the payment. However, for the payee, it may be crucial to Kennard Expires December 14, 2020 [Page 2] Internet-Draft Bank payment URI June 2020 correctly allocate the payment and cause inconvenience and delay if entered incorrectly. In the UK, the Confirmation of Payee (COP) system adds additional complexity as the payee name has to be correctly entered to allow the payment to proceed without an error or a warning. This creates more opportunity for user error. To address all of these issues this RFC proposes a simple URI style for setting up payees and making bank payments. The intended usage is for a link (e.g. href) in a web page, or email, or similar situations where a user can simply click on the link. In addition, the use of 2D barcode systems such as QR codes can easily encode a URI, and many barcode reader applications (and even built in camera functions) will understand a URI and direct the user to a corresponding application on the device. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. URI format The Payment URI scheme name is "pay:" This MUST be followed by an IBAN (International Bank Account Number) This MAY be followed by "/" and a BIC (Bank Identification Code) This is followed by optional "?" and one or more "name=value" pairs, separated by "&" in the style of HTTP URL encoding. 2.1. Example pay:GB89MONZ04000462629119/MONZGB2L?amount=GBP1.00&payee=Andrews+%26+ Arnold+Ltd&reference=A1234A+RFC This example would be used to make a payment of GBP1.00 to Andrews & Arnold Ltd with reference "A1234A RFC" Using abbreviated parameters, it might be encoded in a QR code as PAY:GB89MONZ04000462629119/ MONZGB2L?A=GBP1.00&P=ANDREWS+%26+ARNOLD+LTD&R=A1234A+RFC Kennard Expires December 14, 2020 [Page 3] Internet-Draft Bank payment URI June 2020 As a UK Fast Payment this would be paying sort code 04-00-04, account 62629119. 3. National payments The use of IBAN is for consistency, and does not require that the payment is actually made, or set up, to use some specific international transfer system. Where the IBAN indicates an in- country payment, the application processing the URI MUST extract the relevant local payment credentials from the IBAN quoted in the URI and, set up, or make paymnets using the appropriate national banking system. For example, a UK based mobile banking app should process a GB prefixed IBAN correctly to allow UK Faster Payments bank transfers using a UK sort code and account number. For security reasons, where converting the IBAN to national credentials, such as sort code and account number, the application processing the URI should present these to the user in an appropriate format for the national credentials so that it is easy for the user to check that they are as expected. 4. Character set The URI shall allow direct use of UTF-8 characters in the "value" part. Alernatively these may be "%" escaped in order to ensure only US-ASCII characters are present. For use in QR codes, use of UTF-8 characters is recommended. 5. Minimum URI The minimum URI simply "pay:" followed by an IBAN. A banking application processing this URI SHOULD prompt the user for additional details such as payee name, and amount, etc. In any case where a payment amount is not specified in the URI, the application SHOULD offer the user the choice to either make a payment or to set this up as a new payee for future payments. 6. Defined parameters The following parameters are defined. All are optional. The "name" of each parameter may be in any case, and will typically be in upper case in QR codes to save space. The abbreviated forms of the "name" MUST be accepted by the application, and is recommended when encoding in a QR code to save space. Kennard Expires December 14, 2020 [Page 4] Internet-Draft Bank payment URI June 2020 6.1. amount The amount field is used to specify the currency and value of the payment. The amount field is optional, and if not present then the user may simply be setting up a new payee. The application may prompt the user to set up a new payee or ask for a payment to be made. The amount field MAY be used with a currency and no value in order to specify the preferred currency for setting up a payment. The amount field MAY be specified multiple times with a currency and an amount to be paid for each currency. The application MAY offer the user a choice of currency/amount to pay. If the application is unable to make a payment in one of the currencies specified, it MAY offer payment in another currency if it is able to convert the amount, but MUST warn the user that the amount has been converted from a different currency in such cases and may not be exactly what the payee is expecting to receive. The syntax of the "amount" field is a three character international currency code (e.g. "GBP") and then the value as digits, followed by a decimal point ("."), optionally followed by further digits (e.g. amount=GBP1.23). The value is specified in the units of the currency, e.g. for GBP the amount is in pounds. Where the currency has a fixed number of sub units, e.g. GBP has pence, then the full number of digits SHOULD be specified (e.g. two digits for GBP to show pence). Where the currency has no sub units, the decimal point MUST still be specified and no further digits. An application MUST parse this field strictly. Some currencies allow variable number of digits after the decimal point (e.g. cryptocurrencies). The rationale for this is that it is common for some currencies to use an integer number of sub units (e.g. integer pence) internally in applications and APIs, so as to avoid rounding errors. This relates to each currency and may complicate currency conversion if not known and be impossible for any currency with variable subunits (e.g. crypto currencies). To avoid any ambiguity, and to aid human readability, this amount is in whole currency units (e.g. pounds). The decimal place is used even when no sub units are applied so as to make it clear that this is not some API style "pence" or other integer subunits. The application MUST take necessary precautions to avoid rounding errors, such as parsing as integer sub units internally. If specified, the application MAY prohibit the user from changing the amount (e.g. showing greyed out). If the application allows the user Kennard Expires December 14, 2020 [Page 5] Internet-Draft Bank payment URI June 2020 to change the amount then the application SHOULD warn the user that this is not recommended. The "amount" tag MAY be abbrevaited to simply "a". 6.2. payee The payee name may be specified. This is to be used when setting up a new payee, and if the banking system expects the payee name to be included in the payment. If not specified the application SHOULD prompt the user for a payee name. The "payee" tag MAY be abbreviated to simply "p". For security reasons, any application processing the payment MUST show the payee name in full, and SHOULD prompt the user to confirm this is the payee to which they wish to make payment. It should be noted that in the UK the Confirmation of Payee system requires the payee name to be correct for the account to which the payment is being made. 6.3. reference The payee reference if for the benfit of the payee. If not included then the application SHOULD prompt the user to eneter a reference. If specified, the application MAY prohibit the user from changing the reference (e.g. showing greyed out). If the application allows the user to change the reference then the application SHOULD warn the user that this is not recommended as the reference is for the use of the payee and making changes may cause the payment to be misallocated or delayed. The "reference" tag MAY be abbrevaited to simply "r". 7. QR code Encoding a payment URI in a QR code is a simple way to convey the payment details to the end user that is using a mobile phone or similar device. Where a QR code is shown on a web page the web page SHOULD also include a suitable href/link allowing the user to simply click on the QR code or nearby payment link rather than scanning. This is particularly important as a user may be viewing the web page on a Kennard Expires December 14, 2020 [Page 6] Internet-Draft Bank payment URI June 2020 mobile device as such devices are not usually able to scan a QR code on their own scereen (reference to xkcd 1237). The encoding options to use will depend on the medium but it is recommended that the URI be made as compact as possible. If using all upper case would allow the QR code to be smaller, then this is recommended. URL shorteners MUST NOT be used, the QR code MUST include the payment URI directly. Where the URI includes UTF-8 characters, the QR code SHOULD be encoded using UTF-8 character set. It is RECOMMENDED that URIs avoid use of esoteric characters as banking systems usually operate using very limited character sets. 8. Acknowledgements This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. 9. IANA Considerations This memo includes no request to IANA. Well, that is probably not true as the scheme needs registering... All drafts are required to have an IANA considerations section (see the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 10. Security Considerations Making bank payments simple and easy is, in itself, a security risk. However, banking applications have to consider these risks already, and the alternative of simply manually entering details poses greater risk due to errors being made by end users. A common trick in scams is to show one set of information on a web page or email, the correct information which the user is expecting, but to encode different information within a link or QR code. To mitigate this risk, banking applications SHOULD clearly display the banking details to which a payment is made in a format the end user can understand and making it very clear to which country the payment is being sent. Where possible the application SHOULD also show the account information in a familiar format, for example, using XX-XX-XX XXXXXXXX style format for a UK bank sort code and account number. If Kennard Expires December 14, 2020 [Page 7] Internet-Draft Bank payment URI June 2020 the application can do so, it SHOULD also show the Bank name and branch clearly based on its own data. Displaying this additional information should help avoid security issues, allowing an end user to easily see that the data in a link or QR code is the same as the data they expect. In the UK, and some other countries, the payee may be subject to Confirmation of Payee checks to confirm it matches the payee bank details. These checks SHOULD be performed and any issues or discrepancies shown as would normally be done for such an application where a user has entered the details manually (i.e. it should not be assumed that because the data is machine read from a QR code that such checks can be omitted). 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 11.2. Informative References [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana- considerations-rfc2434bis-09 (work in progress), March 2008. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . Author's Address Kennard Expires December 14, 2020 [Page 8] Internet-Draft Bank payment URI June 2020 Adrian Kennard (editor) Andrews & Arnold Ltd Enterprise Court, Downmill Road Bracknell RG12 1QS UK Phone: +44 5555 400 000 Email: rfc@aa.net.uk Kennard Expires December 14, 2020 [Page 9]