Propositions
From a regulatory compliance perspective the Open Banking PIS functionality of the Write APIs needs to be extended to enable PISPs to initiate international payments from online payment accounts.
Other pages in this section
1. Version control
Version | Date | Authors | Comments |
---|---|---|---|
v0.1 | 05 Apr 2018 | OBIE API Delivery Team | Draft for internal review |
v0.2 | 06 Apr 2018 | OBIE API Delivery Team | For review RLWG, PMG, PAG, SWFG, DWG |
v0.3 | 16 Apr 2018 | OBIE API Delivery Team | Update based on consultation feedback for approval at IESG. See change log for details of all changes. |
v1.0 | 23 Apr 2018 | OBIE API Delivery Team | Final version, approved at IESG on 23 Apr 2018 (no changes from v0.3). |
v1.1 | 08 Oct 2018 | OBIE API Delivery Team | Update MoSCoW, Rationale and add Implementation for Detailed Product Requirements based on Categorisation of requirements for standards and implementation |
2. Roadmap item definition
The Open Banking API’s v1.1 covered single immediate payments (Write functionality) where a PSU can initiate, through a PISP, a one off payment to be initiated immediately from their PCA/BCA account held with an ASPSP.
From a regulatory compliance perspective the Open Banking PIS functionality of the Write APIs needs to be extended to enable PISPs to initiate international payments from online payment accounts, provided and to the extent, that this functionality is available to the PSU, on their ASPSPs’ online payment account, in alignment with the requirements of PSD2.
The international payments to be covered by the new PIS functionality include:
- SEPA payments (normal and instant where appropriate)
- SWIFT payments
- RTGS on Target2
- EBA Euro1
- International transfers and currency transfers (PSU’s domestic account to PSU’s overseas account)
Note: For detailed list of payment types, please refer to section 10.11 of the Appendix.
This paper defines the overall proposition to support this extended API functionality, so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) have a common understanding about what is and is not in scope, and how this proposition will support regulatory requirements and key use cases.
For actual roadmap item definition and problem statement, please refer to sections 10.3 and 10.4 of the Appendix.
3. Market analysis
Macroeconomic factors influence trade between countries and this can have direct impact on international payments. While presenting steady growth between 2010 and 2014, international payments declined in 2015 due to lower international trade, caused by slow recovery in Europe and slowdown in China. The international payments market in 2015 was estimated to have a transaction volume of US$22 trillion and it is expected to grow by approximately 4.6% over the next five years. Emerging markets are showing higher growth rate compared to mature markets. (EY, #payments, insights, opinions. Volume 16, 2017)
There are 4 main categories of international payments:

a) Supplier or Business to business (B2B): These are made when one enterprise pays another. The payments may be made to regular, well-known parties or to occasional or one-time suppliers. In these transactions, the supplier frequently extends credit to the buyer—or may demand a letter of credit or other form of credit assurance. (Glenbrook Partners, Cross-Border Payments Perspectives, 2011). B2B has the highest transaction value of the four segments with US$21 trillion in 2015 (>95% of total). Growth in this segment is primarily driven by growth in small and medium sized enterprises (SMEs). Transaction sizes for these SMEs tend to be lower in value resulting in slow growth of transaction value in the B2B segment. However, transaction volumes have increased and have in turn demonstrated strong growth (EY, #payments, insights, opinions. Volume 16, 2017).
For UK SMEs the following hold: (Accourt, Bank charges on international payments, An analysis of the UK SME market)
- International trade is worth over £700bn,
- £365.3bn within the EU, £162.92bn of which are outgoing payments (SEPA payments)
- For non-EU countries the international trade value was £360.5bn in 2014
b) eCommerce purchasing / Consumer to business (C2B): These include not only the purchase of physical goods (with all of the challenges of shipping, customs, and taxation) but also the travel and entertainment, digital services, and digital goods domains (Glenbrook Partners, Cross-Border Payments Perspectives, 2011).
- Retail international volume is poised to take over the business to business market within the next 10 years.
- Currently represents US$340 billion (1.5% of total) and at 25% has the highest growth rate across all the other segments over the past five years.
- Growth mainly been driven by e-commerce transactions and online sales.
- Payment margins tend to be richer than in B2B, but current competition and market concentration have driven margins down.
- Merchants are mainly responsible for driving the shift to e-commerce as they find opportunities to expand their international market through marketplaces, such as Amazon and eBay. At the same time, shoppers, especially in emerging markets, are increasingly buying abroad.
- Payment service providers, like Amazon Payments, Alipay and PayPal, have built up the capacities to serve this growing market by managing payments functions, such as currency handling in-house, which is affecting the overall retail market economy and driving margins down (EY, #payments, insights, opinions. Volume 16, 2017)
c) Payroll, retirement, and benefits payments / Business to consumer (B2C): These are made by enterprises to counterparties in other countries. The payees are most often individuals, but this category can also include various B2B-like payments to licensees, franchise participants, and digital contract laborers (Glenbrook Partners, Cross-Border Payments Perspectives, 2011).
- B2C is the smallest segment across the international payments, but it is expected to accelerate its growth because of globalized workforces and independent cross-border contractors. (EY, #payments, insights, opinions. Volume 16, 2017).
d) International remittances / Consumer to consumer (P2P): These are payments made by foreign workers to family members in home countries. As any given worker is apt to make payments to only one country, this domain is measured by country pairs, or “corridors.” (Glenbrook Partners, Cross-Border Payments Perspectives, 2011)
- P2P represents US$600 billion (2.7% of total) with a growth rate of 5% over the last five years.
- The growth has slowed because of macroeconomic factors, such as lower oil prices affecting the economy and tighter immigration controls.(EY, #payments, insights, opinions. Volume 16, 2017)
3.1 Observations for SME B2B behaviour on international payments
- Most companies (90%) use banks to send payments internationally rather than using nonbank FX providers or other means of payment (e.g. cards)
- 68% of companies use a bank to send payments internationally for reasons other than pricing, speed of delivery or because they provide the best FX rates
- Other reasons given for using a bank included credit, existing relationship with their bank, the daily use of online banking applications within a companies’ business, convenience, or because firms had never thought of using an alternative method
- The majority of payments (89%) are individual rather than bulk payments
The detailed market analysis can be found in section 10.6 of the Appendix.
4. Customer use cases
OBIE has conducted both primary customer research and secondary market research to identify the existing market offerings and requirements around international payments. In addition, a series of market engagement workshops are being conducted to validate the requirements, especially from the TPP perspective. The following high level use cases that require international payments capabilities were identified. Understanding these allows OBIE to identify the key requirements needed to deliver these use cases.
ID | Use Case | Met |
---|---|---|
UC1 – Supplier Payments (B2B) from invoicing | As a Business Customer, I want to be able to use my invoice management system to directly make international payments in Euro and other currencies from my UK GBP bank accounts or other currency accounts, via a PISP, to suppliers’ accounts in Europe and Rest of the World (ROW), so that I can import the goods and services necessary for my business. | Fully |
UC2 – eCommerce goods and services (C2B) | As a Consumer, I want to be able to allow, via a PISP, international payments in Euro and other currencies to be initiated directly from my UK GBP account or other currency account to an online merchant’s banks account abroad, so that I can buy goods and services. | Fully |
UC3 – Business to Consumer Payments (B2C) from accountancy package | As a Business Customer, I want to be able to use my accounting package to initiate an international payment in Euro and other currencies, via a PISP, directly from my UK GBP account or other currency account to my remote employees, licensees, franchise participants, and digital contract laborers’ bank accounts in Europe and Rest of the World (ROW), so that I can run my remote business operations. | Fully |
UC4 – International remittances (P2P) directly from Bank | As a Consumer, I want to be able to use a third party application to send international payments in Euro and other currencies directly from my UK GBP account or other currency account, via a PISP, to my home country, so that my local family members can receive the funds. | Fully |
UC5 – International remittances (P2P) using Remitter’s service | As a Consumer, I want to be able to make international payments abroad in all currencies using a Remitter Service, by funding the payment from my UK GBP bank account, via a PISP, so that I can benefit from the completive FX rates offered by the Remitter. Note: The above use case is classified as ‘domestic payments’ from the Open Banking perspective and thus is considered to be out of scope for this roadmap item. | No |
Open Banking has conducted quantitative and qualitative research to gauge the customer feedback on a few payment journeys for this proposition and to identify areas of improvement. The customer research outcome can be found in section 10.7 of the Appendix. 2 prototypes developed to demonstrate the expected high level user journeys. These can be found in section 10.6 of the Appendix.
5. Regulatory references
- The scope of roadmap item P10 should create the functionality to enable a PISP, with the PSU’s consent, to request for an ASPSP to execute an international payment order, if and to the extent, this functionality is available to the PSU on their online payment account.
- Under RTS Art 36(4), there is requirement for the PISP to provide the ASPSP the same information as requested from the PSU when initiating the payment transaction directly. This will require the PISP to provide the ASPSP with specific information to execute an international payment order, as required from the PSU when directly initiating an international payment from an online, payment account. The information can differ depending on the type of international payment. OBIE will be dependent on ASPSPs to specify their particular information requirements to ensure the appropriate API functionality is built to facilitate this.
- Under the PSR, Regulation 69(2)(b) and RTS Article 36(1)(b), the information requirements regarding the status of international payments will need to consider the “information on the initiation and execution” available immediately after receipt of the payment order. This will include:
(a) what ASPSPs provide to PSUs
(b) what is accessible to ASPSP at this same point in time
(c) what PISPs require in order to support their regulated businesses (optional).
- Any status information requirements that fall outside the scope of (a) – (c) above, will form part of the P9: Status of Payment Evaluation.
5.1 Other regulatory considerations
- PSR, Regulation 45 (2) stipulates the information requirements that the ASPSP must provide or make available to the PSU after receipt of a payment order for single payment service contracts. Further when there is a framework contract in place, Reg 52, requires the ASPSP to inform the PSU (upon request) with specific information related to individual payment transaction. The provision of this information by the ASPSP to the PSU is strictly within the domain of the ASPSP.
- If ASPSPs consider useful, it can be assessed whether OBIE functionality can enable the transmission of this information via the Open Banking APIs, as optional fields.
- These items are currently assessed under roadmap item P19, which require confirmation from ASPSPs on whether there is a regulatory requirement to assess the building of this functionality by OBIE. In the context of international payments, information relating to the exchange rate and charges could create a valuable functionality if supported by the OBI APIs but appears not to be required by the PSRs.
For detailed Regulatory references, please refer to section 10.2 of the Appendix.
6. Evaluation criteria
Key evaluation criteria that OBIE have applied for this proposition (that respect the objectives of meeting regulatory requirements as well as being effective and proportionate)
- Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
- Is the proposition implementable at reasonable cost?
- Does the proposition comply with all relevant regulations?
7. Product requirements
OBIE understands that the international payments proposition may need to support the following functionality:
- PISP to initiate international payments with the consent of the PSU; ASPSP to execute these international payment orders
- PISP to be able to transmit to the ASPSP all information required to enable the ASPSP to execute an international payment.
- Ability to support all international payment types offered by the ASPSPs online platforms and rates quoted to customer whether in the TPP application or ASPSP portal post-authentication.
- International payments support for all accounts defined in item P20 for PIS access, provided that the functionality is available to the PSU on their ASPSP’s online, payment account. In addition, currency accounts will also be supported as per roadmap P21.
- Ability for PISP to prepopulate or collect from the PSU and pass to the ASPSP as part of the international payment setup all the information required so that customer does not have to complete these in the domain of their the ASPSP has all the necessary information to initiate the payment (refer to AML – Required Bank Details in section 10.9).
- Ability for ASPSPs to advise the PSU (either within the ASPSP domain or optionally via the PISP) of the bank charge(s) and breakdown (if applicable) and the actual or reference exchange rate prior to the customer authorizing an International Payment.
- Ability for PSU to cancel with the ASPSP all international payment authorisations pending to be executed (up to business Day -1) provided this functionality is available online, for example, for future dated international payments. This can only happen in cases where the FX conversion of the payment is executed on settlement date. If the FX payment is executed (i.e. the PSU account debited) in advance of settlement, then the payment cannot be cancelled.
The following are not considered to be included in the requirements for this specific proposition:
- International payments, executed by an FX Provider TPP, which are funded by the PSU’s GBP account with the ASPSP through Open Banking (i.e. they are considered domestic payments for Open Banking domain).
- Payment execution status, customer non-present (CNP) international payments, corporate accounts and international payments refunds (they are all covered by other roadmap items).
For detailed list of Product Requirements, please refer to section 10.1 of the Appendix.
8. Considerations
8.1 Constraints
- For Payment Initiation, the only “One-leg Out” case to be considered is the one where the ASPSPs are in EEA and the payer is making an international payment from a UK GBP account or other currency account outside the EEA using any currency.
- An international payment cannot be initiated from an account type in scope of P20, if this account does not support international payments.
- International payments cannot be initiated from currency accounts as per item P21, if currently not supported by ASPSPs.
8.2 Dependencies
- The payer’s ASPSP is offering foreign exchange conversion (ASPSP domain) on the online, payment account.
- The payer’s ASPSP support international payments for the selected countries and currencies (ASPSP domain) on the online, payment account.
- Roadmap item P11 has strong dependency on roadmap item P10 in relation to the execution of all payment types of batch/bulk international payments (eg SEPA bulk payments). The format of these batch/bulk payments will be covered during the discovery of item P11 so the current scope of P10 is for single payments only and will feed in information of payment format to P11 to enable batch/bulk payments.
8.3 Assumptions
- Similarly, to international payments orders currently executed by the ASPSP, all mandatory sanctions and AML checking will be performed by the ASPSP based on the information provided by the TPP.
- International payments with future date will be warehoused in the ASPSP (subject to item P5 decision), in case their FX conversion is not to be executed immediately.
- International payments beneficiaries do not need to be Trusted Beneficiaries.
- Ability to perform recurring international payment will be explored once the related position on item P5 is agreed.
- The sending ASPSP will be performing the FX conversion if required.
9. Adoption Metrics
The following metrics will be required to measure the adoption of the international payments proposition:
- Number of TPPs initiating international payments of all types using Open Banking.
- Number of customer authorisations for international payments to ASPSPs.
- Volume of successful transactions generated by each international payment type.
- Volume of failed transactions, by type of failure, for each international payment type.
10. Appendix
10.1 Detailed product requirements
These are stated as requirements of the OBIE solution to enable implementers to meet regulatory compliance and/or customer use cases.
Requirements marked as ‘M'(Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is ‘mandatory’, ‘conditional’ or ‘optional’ for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation.
ID | Requirement | MoSCoW | Rationale | Use Cases | Implementation |
---|---|---|---|---|---|
1 | OBIE’s Solution(s) must support payments initiation in international currencies & cross-border payments | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
2 | The OBIE’s Solution(s) must allow a PISP to transmit or confirm the PSU’s consent to the execution of an international payment transaction | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
3 | OBIE’s Solution(s) for international payments must enable PISPs to initiate payer-initiated payment transactions from all types of payment accounts. | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
4 | A) The OBIE solution should allow ASPSPs to support both un-booked foreign exchange rate or pre-booked FX rate with ASPSP as per the ASPSPs current international payments capabilities (i.e. if currently supported online) B) The OBIE solution should allow ASPSPs to be able to offer a FX quote with the validity period to the PISP without the need to identify a PSU. This should provide the ability for the PISP to present this quote to the PSU, so that when the PSU does initiate the payment order with the ASPSP it is against that quote. | M | Customer | UC1, UC2, UC3, UC4 | Conditional(Required for parity with current online solutions. See Article 36 Para 1(b) of RTS) |
5 | ASPSPs (either within the ASPSP domain or optionally via the PISP) should be able to advise the PSU of the bank charge(s) and breakdown (if applicable) and the actual or reference exchange rate prior to the customer authorizing an International Payment. The OBIE’s Solution(s) for international payments could – subject to mutual agreement – provide information to the PSU (via PSU’s PISP) on the applicable execution time and charges (with breakdown) from the payer’s ASPSP in the case where there is a framework contract Note 1: Any provision of charges can only be those of the ASPSP as the Beneficiary’s bank charges are not known in many cases. Note 2: Where the final charges are not known to the ASPSP, the responsibility should remain with the ASPSP for notifying the customer of the charges as per the PSD2 regulatory requirements. Note 3: The above cases need to be identified during the details discovery and specification phase and clearly documented as proposition constraints in the customer guidelines. | M | Customer | UC1, UC2, UC3, UC4 | Refer to Customer Experience Guidelines |
6 | The OBIE’s Solution(s) should support the ASPSP’s provision of Payment Reference Number, Date, Amount, Charges and (if applicable) exchange rate to the payer for single payment service contracts [NB – dependency on OBIE to be assessed] | M | Regulatory | UC1, UC2, UC3, UC4 | Refer to Customer Experience Guidelines |
7 | The OBIE’s Solution(s) for international payments should allow the revocation of a future dated payment order up to and including the business day prior to execution of the payment order by the ASPSP. This can only happen in cases where the FX conversion of the payment is executed on settlement date. If the FX payment is executed (i.e. the PSU account debited) in advance of settlement, then the payment cannot be cancelled. | M | Customer | UC1, UC2, UC3, UC4 | Refer to Customer Experience Guidelines |
8 | The OBIE’s Solution(s) must enable the ASPSP to request the same information from the PISP as is requested from the PSU when making an international payment directly.In relation to international payments, This could include country specific AML requirements (refer to AML – Required Bank Details section 10.9 of the Appendix) | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
8.5 | The OBIE’s Solution(s) must allow exchange of information between ASPSP and PISP immediately after receipt of the payment order. | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Information that’s I available to the ASPSP regarding e.g. status must be made available to the PISP)Refer to Customer Experience Guidelines |
9 | PSU could be able to cancel with the PISP all international payment authorisations pending to be executed (upto business Day -1) provided this functionality is available online (in alignment with the roadmap item P5 proposition) | C | Customer | UC1, UC2, UC3, UC4 | Future Consideration(There is no regulatory requirement nor any immediate propositional need for this capability) |
10 | PISP must be able to receive from the ASPSP a quotation to be used by the ASPSP for a specific currency conversion pair and the time window that this FX rate is valid so that they can inform the PSU before initiating the paymentNote1: Need to further identify which aspects of the FX can change and whenNote2: ASPSPs may reject payments against quotations that have expired. | M | Customer | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
11 | PISP must be able to receive from the ASPSP the charges (actual or indicative?) that may be applied to the payment Originator or the Beneficiary (subject to allowable charge models for the payment) so that they can inform the PSU before payment initiation | M | Customer | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
12 | PSU must be able to view with both the AISP and the ASPSP all future dated international payments. | M | Customer | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
13 | PISP must be able to receive from the ASPSP all the cut-off times for all the international payments before the PSU initiates the payment from the PISP.Note: There are two cut-off times to consider for International payments. The cut-off time for execution of the instruction and the cut-off time for the currency being sent. The latter impacts the credit value date of a payment along with bank holidays and urgency of the instruction. | M | Customer | UC1, UC2, UC3, UC4 | Conditional(Mandatory for TPPs to know what is supported by ASPSP) |
14 | International payments functionality must be supported for non-GBP currency accounts (see roadmap item P21).Note: This is now part of the requirement 1. | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
15 | International payments functionality must be supported for accounts where multiple authorisations are required (see roadmap item P13). | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
16 | The OBIE’s Solution(s) for international payments must allow the ASPSP to return the status of the payment immediately after the receipt of the payment order. | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
17 | The OBIE’s Solution(s) must enable the PISP to return a confirmation of successful initiation to the PSU along with the payment amount and charges applied by the PISP (with breakdown where applicable) for an international payment | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
18 | The OBIE’s Solution(s) must enable AISPs to access account information on all types of payments, including international payments.[nb: the above requirement relates to functionality that should be enabled through the OBIE’s Solution(s) rather than the mandating of its use]The OBIE’s Solution(s) must allow the ASPSP to provide the AISP with the information [excluding sensitive payment data] available to the PSU via their online account. | M | Regulatory | UC1, UC2, UC3, UC4 | Conditional(Mandatory if provided by ASPSP in existing channel) |
19 | Corporate accounts (see item P22). | C | Customer | Future Consideration(Will be covered under P22) | |
20 | Customer Not Present (CNP) use cases (see item P8) | C | Customer | Future Consideration(Will be covered under P8) | |
21 | Status of the Payments over and above requirement 16 above (see item P9) | C | Customer | Future Consideration(Will be covered under P9) | |
22 | Refunds of Payments (see item P7) | C | Customer | Future Consideration(Will be covered under P7) | |
23 | International payments, executed by an FX Provider TPP, which are funded by the PSU’s GBP account with the ASPSP through Open Banking (domestic payments for Open Banking domain) | C | Customer | Future Consideration(Not considered a regulatory requirement) | |
24 | SEPA Direct Debits instructions submissions | C | Customer | Future Consideration(There is no regulatory requirement nor any immediate propositional need for this capability) |
10.2 Regulatory references
The following regulatory references are relevant when considering the scope of item P10:
- FCA Approach Document (17.27):
“In order to meet this requirement, we expect ASPSPs to allow each customer to initiate a payment via a PISP to the same level of functionality that is available to a customer if they initiate a payment directly with their ASPSP. ASPSPs are not, however, required to provide functionality via a PISP that exceeds the functionality they offer to their customers directly”
OBIE View:
Scope of P10 should create the functionality to enable a PISP, with the PSU’s consent, to request for an ASPSP to execute an international payment order, if and to the extent, this functionality is available to the PSU on their online payment account.
- RTS Article 36(4):
“Payment initiation service providers shall provide account servicing payment service providers with the same information as requested from the payment service user when initiating the payment transaction directly.”
OBIE’s View:
Under RTS Art 36(4), there is requirement for PISP to provide ASPSP the same information as requested from the PSU when initiating the payment transaction directly. This will require PISP to provide ASPSP with specific information to execute an international payment order, as required from the PSU when directly initiating an international payment from an online, payment account.
This information can differ depending on the type of international payment. OBIE will be dependent on ASPSPs to specify their particular information requirements to ensure the appropriate API functionality is built to facilitate this.
- PSR, Reg 69(2)(b)
Information requirements for both ASPSPs and PISPs applicable to all PISP initiated payments PSR, Reg 69(2)(b):
“immediately after receipt of the payment order from the payment initiation service provider, provide or make available to the payment initiation service provider all information on the initiation of the payment transaction and all information accessible to the account servicing payment service provider regarding the execution of the payment transaction”
RTS Article 36(1)(b):
“Account servicing payment service providers shall comply with each of the following requirements… they shall, immediately after receipt of the payment order, provide payment initiation service providers with the same information on the initiation and execution of the payment transaction provided or made available to the payment service user when the transaction is initiated directly by the latter”
OBIE’s View:
Under the PSR, Regulation 69(2)(b) and RTS Article 36(1)(b), the information requirements regarding the status of international payments will need to consider the “information on the initiation and execution” available immediately after receipt of the payment order. This will include:
(a) what ASPSPs provide to PSUs
(b) what is accessible to ASPSP at this same point in time
(c) what PISPs require in order to support their regulated businesses (optional).
Any status information requirements that fall outside the scope of (a)– (c) above, will form part of the P9: Status of Payment Evaluation.
- PSR, Reg 45:
(1) The payer’s payment service provider must, immediately after receipt of the payment order, provide or make available to the payer the information specified in paragraph (2) in relation to the service to be provided by the payer’s payment service provider.
(2) The information referred to in paragraph (1) is—
(a) a reference enabling the payer to identify the payment transaction and, where appropriate, information relating to the payee;
(b) the amount of the payment transaction in the currency used in the payment order;
(c) the amount of any charges for the payment transaction payable by the payer and, where applicable, a breakdown of the amounts of such charges;
(d) where an exchange rate is used in the payment transaction and the actual rate used in the payment transaction differs from the rate provided in accordance with regulation 43(2)(d), the actual rate used or a reference to it, and the amount of the payment transaction after that currency conversion; and
(e) the date on which the payment service provider received the payment order.
PSR, Reg 52:
Where an individual payment transaction under a framework contract is initiated by the payer, at the payer’s request the payer’s payment service provider must inform the payer of—
(a) the maximum execution time;
(b) the charges payable by the payer in respect of the payment transaction; and
(c) where applicable, a breakdown of the amounts of such charges.
OBIE’s View:
In both instances, this information and how is made available to PSU is strictly within the domain of the ASPSP. If ASPSPs consider useful, it can be assessed whether OB functionality can enable the transmission of this information via the OB APIs, as optional fields.
These items are currently assessed under P19, which require confirmation from ASPSPs on whether there is a regulatory requirement to assess the building of this functionality by OBIE. In the context of international payments, information relating to the exchange rate and charges could create a valuable functionality if supported by the OBI APIs but appears not to be required by the PSRs.
10.3 Roadmap item definition
The following table is taken ‘as-is’ from the published roadmap:
(https://www.openbanking.org.uk/wpcore/wp-content/uploads/2017/11/FAO-CMA_Proposed-Amendments-to-Agreed-Arrangements_v_final-1.pdf)
P10 – International Payments
Description | Rationale | Aligns with |
---|---|---|
Scope Item description:Extension of write (PIS) functionality of the OB R/W APIs to cover international payments (including but not limited to SEPA payments) from sterling current accounts in alignment with the requirements of PSD2 Key activities:A discovery phase by the OBIE to understand the variety of international payment types and models and create the business requirements for the standardsThe development of standards by the OBIE for the products and functionality referred to above (and leveraging the learning from the development of international payments standards in item P.19 of the OB Roadmap)The implementation of those standards by the CMA9 for Release 3 | Regulatory alignment:Fulfils the requirements of the Order by aligning with PSD2 Open Banking adoption:Extends coverage of OB Standards to TPPs focused on the FX market Consumer / SME utility:Consumers would be able to execute non-sterling payments through TPPs Security / Integrity:Consumers would be able to execute payments conveniently without putting cards on file | PSD2 |
10.4 Problem statement
Note: This is not a problem statement for the Open Banking P10 item but a problem statement of the general international payments market.
Secondary market research performed by the OB Read/Write team has identified the following challenges with international payments
- Lack of transparency
- There is lack of transparency concerning the FX charges and high transaction costs which banks and other financial firms impose on cross-border transactions (EY, #payments, insights, opinions. Volume 16, 2017)
- Inefficient processes:
- The process of making cross-border payments is too cumbersome, unpredictable and it takes a long time (EY, #payments, insights, opinions. Volume 16, 2017)
- Limited infrastructure capabilities
- Banks have long been reliant on the payment infrastructure that has been established over the years and that lacks modern capabilities and efficiencies. (EY, #payments, insights, opinions. Volume 16, 2017)
- Accelerating revenue-margin compression
- Historically international payments revenue margins remained healthy and price erosion moderated due to not facing the same systemic pressures as domestic payments. No structural cost-reducing processes introduced across the industry result in high operational cost per transaction. (McKinsey & Company, Global Payments 2016: Strong Fundamentals Despite Uncertain Times, 2016)
- Difficulty to integrate into financial workflows
- International payments services from banks are extremely difficult to integrate into financial workflows providing SMEs with a major headache. (Money Mover UK SME International Payments Analysis, 2016)
The OBIE proposition for international payments must meet the roadmap requirements in line with applicable regulatory requirements. Further consideration may look to address some of these challenges insofar.
10.5 Detailed market research
The following section details the findings from secondary research in relation to international payments.
10.5.1 Global International Payments Market Segmentation
Growing global economy and international trade has allowed consumers and businesses to sell and acquire products and services across global markets. This has resulted in the rise of international payments which has seen steady growth over the last few years. The main factors influencing the rise of international payments are: i) the accelerated growth in global businesses, ii) the consumer preference for mobile and digital, and iii) the disruptive players shaping global payments (EY, #payments, insights, opinions. Volume 16, 2017).
Macroeconomic factors influence trade between countries and this can have a direct impact on international payments. While presenting a steady growth between 2010 and 2014, international payments declined in 2015 due to lower international trade. This was impacted by the slow recovery in Europe and slowdown of China’s economic growth rate. The international payments market in 2015 was estimated to have a transaction volume of US$22 trillion and it is expected to grow by approximately 4.6% over the next five years. Emerging markets are showing a higher growth rate of international payments compared with mature markets. (EY, #payments, insights, opinions. Volume 16, 2017)
10.5.2 International Payments Market Segmentation
There are 4 main categories of international payments:
a) Supplier or Business to business (B2B): These are made when one enterprise pays another. The payments may be made to regular, well-known parties or to occasional or one-time suppliers. In these transactions, the supplier frequently extends credit to the buyer—or may demand a letter of credit or other form of credit assurance. (Glenbrook Partners, Cross-Border Payments Perspectives, 2011)
B2B has the highest transaction value of the four segments with US$21 trillion in 2015 (>95% of total). Over the last five years, B2B segment growth has slowed down to 2%, however, the transaction volume increased significantly to 9%. Growth in this segment is primarily driven by growth in small and medium sized enterprises (SMEs), which are trading more across borders. SMEs now represent 25% of international trade in the B2B segment (circa US$5.25 trillion). Transaction sizes for these SMEs tend to be lower in value resulting in slow growth of transaction value in the B2B segment. However, transaction volumes have increased and have in turn demonstrated strong growth. The B2B segment consists of international exports and imports of merchandise and commercial services. Global merchandise represents the majority of B2B business. However, transaction value has decreased over the past few years because of volatility in commodity prices. On the other hand, trade in commercial services has grown at a faster rate where travel, telecommunication and professional services represent more than half of international commercial services. The US and EU still dominate B2B transactions, representing almost 40% of international trade (including intra-EU trade). However, the APAC region is becoming one of the most important regions for international trade, representing almost 20% of international trade (where countries like China and India continue to grow at a faster rate than other markets) (EY, #payments, insights, opinions. Volume 16, 2017).
b) eCommerce purchasing / Consumer to business (C2B): These include not only the purchase of physical goods (with all of the challenges of shipping, customs, and taxation) but also the travel and entertainment, digital services, and digital goods domains (Glenbrook Partners, Cross-Border Payments Perspectives, 2011).
Retail international volume is poised to take over the business to business market within the next 10 years. It currently represents US$340 billion (1.5% of total) and at 25% has the highest growth rate across all the other segments over the past five years. C2B growth has mainly been driven by e-commerce transactions and brick and mortar online sales. Retail payment margins tend to be richer than in B2B, but current competition and market concentration have driven margins down. Merchants are mainly responsible for driving the shift to e-commerce as they find opportunities to expand their international market through marketplaces, such as Amazon and eBay. At the same time, shoppers across borders, especially in emerging markets, are increasingly buying abroad. This has benefited the C2B cross-border industry, which currently represents 20% of the overall e-commerce industry (US$1.7t in 2015) and it is expected to be 30% within the next 10 years. The C2B segment is moving toward a seamless experience in marketplaces operating similarly across borders and driving international consumer spending. Payment service providers, like Amazon Payments, Alipay and PayPal, have built up the capacities to serve this growing market by managing payments functions, such as currency handling in-house, which is affecting the overall retail market economy and driving margins down (EY, #payments, insights, opinions. Volume 16, 2017)
c) Payroll, retirement, and benefits payments / Business to consumer (B2C): These are made by enterprises to counterparties in other countries. The payees are most often individuals, but this category can also include various B2B-like payments to licensees, franchise participants, and digital contract laborers (Glenbrook Partners, Cross-Border Payments Perspectives, 2011).
This segment is mainly focused on businesses paying out payroll, pensions or benefits to offshore employees and contract laborers. E-marketplaces are offering businesses opportunities to provide services and goods to consumers. This segment includes e-marketplaces of services and goods providers, larger corporations paying freelancers (e.g., app developers) and multi-level marketing. B2C is the smallest segment across the international payments, but it is expected to accelerate its growth because of globalized workforces and independent cross-border contractors. This segment represents US$128 billion (0.5% of total) with a growth rate of 7% over the past five years. It has moderate margins, which is a result of low margins enjoyed by corporates B2P, but partially offset by high margins in freelancing payments (EY, #payments, insights, opinions. Volume 16, 2017).
d) International remittances / Consumer to consumer (P2P): These are payments made by foreign workers to family members in home countries. As any given worker is apt to make payments to only one country, this domain is measured by country pairs, or “corridors.” (Glenbrook Partners, Cross-Border Payments Perspectives, 2011)
P2P is mainly driven by remittances sent back to the home countries of expats and cross-border contractors who are temporarily working abroad. P2P represents US$600 billion (2.7% of total) with a growth rate of 5% over the last five years. The growth has slowed because of macroeconomic factors, such as lower oil prices affecting the economy and tighter immigration controls. The transaction value of international remittances has been increasing over the past few years. However, the margin continues to decline because of increasing competition and the adoption of new technology. P2P uses a variety of payment methods with varying margins, with the more concentrated volumes of large merchants or concentrated intermediaries tending to have lower margins than more highly fragmented ones. Besides traditional remittances, there are other categories, such as international students’ families sending money to pay tuition and living expenses, which is gaining momentum with the growth of international students. The other category that is also gaining traction is medical tourism (EY, #payments, insights, opinions. Volume 16, 2017)
10.5.3 Profitability of Global International Payment Types
While international payments account for less than 20% of total payments volumes, they comprise about 40% of global payments transactional revenues, and generated $300 billion in global revenues in 2015. At a granular level, major differences exist in revenue contribution and associated revenue margins depending on the nature of the transaction (e.g., trade versus treasury), the geographic corridor and the end customers involved (consumer or commercial). (McKinsey & Company, Global Payments 2016: Strong Fundamentals Despite Uncertain Times, 2016)
On one hand, consumer-to-consumer (P2P) remittances generate a healthy 6.2/% global average revenue margin (including fees and foreign exchange margins). This resulted in $25 billion of global international payments revenue which is 8% of total revenues. On the other hand, higher value business-to-business (B2B) payments brought in $240 billion revenue, resulting in revenue margin of circa 20 basis points which is quite lucrative. Given the average transaction value of $15,000 to $20,000, this implies a typical fee of $30 to $40 per transaction. (McKinsey & Company, Global Payments 2016: Strong Fundamentals Despite Uncertain Times, 2016).
Since 2011, the annual international payments revenue growth has not exceeded 4% and reached a post-crisis low in 2015 with 2% growth. The muted growth is mostly attributable to slowing global trade and GDP, and reinforced by gradually eroding revenue margins (annual decreases averaging 2% between 2011 and 2015). The impact of this negative climate is felt more keenly in B2B payments. These payments drive roughly 80% of international payments revenues. Banks retain a near 90% share of this segment. McKinsey projects an average CAGR of 4% for the period 2015-20, assuming revenue margin compression continues at the same pace as in the recent past (McKinsey & Company, Global Payments 2016: Strong Fundamentals Despite Uncertain Times, 2016)
The historical persistence of relatively high revenue margins on international payments is due in part to the fact of facing the same systemic pressures as domestic payments. Forced to reduce domestic fees in the wake of heightened regulation and increasing competition over recent decades, banks responded with drastic cost reductions for domestic transaction handling through front-end automation, process simplification, standardization and outsourcing and development of new applications for existing payments products. As international payments did not face the same regulatory and competitive pressure, banks have had little incentive to innovate structurally on customer offerings, back-end systems and processes. And as international payments revenue margins remained healthy and price erosion moderated, no structural cost-reducing processes were introduced across the industry. As a result, operational cost per transaction for international payments continues to average well above $20 (these costs vary widely across institutions and between cross-border corridors). Over the last few years, however, this situation has been challenged by structural developments. While these challenges yet have to drive meaningful fluctuations in market share, there are clear signs of accelerating revenue-margin compression and customer pressure making the current situation unsustainable, in terms of revenue levels, but also system efficiency. This makes the case for urgent and fundamental change to the correspondent banking business (McKinsey & Company, Global Payments 2016: Strong Fundamentals Despite Uncertain Times, 2016).
The International Payments proposition of Open Banking is expected to impact both SMEs and Consumers.
10.5.4 International Payments by the UK SME Market (B2B)
UK SMEs import goods from multiple suppliers abroad who need to receive payments for delivering the goods. SME companies are making a large portion of these international payments to their suppliers using online banking platforms. 90% of companies are executing payments online (financial-i, International Payments Survey, 2011).
In 2016, the total value of UK imported goods was £468bn. Of this, £141bn was generated by SMEs (i.e. businesses with less than 250 employees), with 149,000 SMEs importing goods from the EU of total value of £80bn. Moreover, Non-EU imports reached a value of £61bn, generated by 89,000 UK SME businesses. The total number of people employed by these SMEs was 2.8m (HMRC, UK trade in goods statistics by business characteristics 2016)
The Eurozone is still the largest import trading partner, but non-EU trade has grown much faster in recent years. The top country of imports for UK businesses is Germany, followed by the US, Netherlands and China (HMRC, Summary of Import and Export Trade with EU and Non-EU Countries – Annual 2009 – 2017). Trade with the EU is overwhelmingly settled in Euros. The U.S. Dollar is the most popular currency in which to be invoiced from non-EU countries (65.6% of value). Sterling, with 22.7% of the total, was the second most popular currency in which UK companies were invoiced for imports, followed by the Euro (5.2%) and Canadian Dollar (2.8%) (Accourt, Bank charges on international payments, An analysis of the UK SME market).
10.5.4.1 Observations for SME B2B behaviour on international payments
Important points to note (financial-i, International Payments Survey, 2011):
- Most companies (93%) use banks to send payments internationally rather than using nonbank specialist FX providers or other means of payment (cards, online)
- The majority of payments (89%) are individual rather than bulk payments
- 68% of companies use a bank to send payments internationally for reasons other than pricing, speed of delivery or because they provide the best FX rates
- Other reasons given for using a bank included credit, existing relationship with their bank, the daily use of online banking applications within a companies’ business, convenience, or becausefirms had never thought of using an alternativemethod
For UK SMEs, international trade is worth over £700bn, of which £365.3bn takes place within the EU, £162.92bn of which are outgoing payments (SEPA payments) (2014 figures). Based on this last figure the transfer costs for these payments were estimated to be £3.96bn. For non-EU countries the international trade value was £360.5bn in 2014. (Accourt, Bank charges on international payments, An analysis of the UK SME market)
10.5.5 Issues Identified
There are some challenges involved in trading abroad, whether exporting or importing. In addition to currency risk, currency costs and foreign payments issues are a major concern, especially for SMEs. However, these costs are all too often seen as an ‘inevitable’ cost of dealing with foreign currencies. In general terms UK banks lack transparency on currency exchange rates and margins. Each bank generates its own FX rate for the day and it is provided by an internal system which customers do not have access to. In some instances the bank’s exchange rate is not even provided before confirming the payment so it is unknown to the customer how much is going to be charged for the transaction. (Accourt, Bank charges on international payments, An analysis of the UK SME market)
Banks researched during this analysis show a common lack of transparency in divulging the spread costs (on the other hand, fees are publicly available in most cases). In general terms, the SMEs need to be a bank customer or make a real payment in order to get information on the spread and the total cost of the transaction. Some banks do not even guarantee an exchange rate until the transfer has been made. This makes the comparison and decision making process extremely challenging for the SMEs. Banks’ FX rates are automatic, system-generated rates which vary by the minute/hour based on a number of parameters. The banking sector does not offer a clear breakdown of the costs. While almost all of them show the transaction fees on their website there is no public information on foreign exchange rates (not even when a customer rings the bank), which is where the majority of the profits on the transactions are derived. Rates tend to get better as the transfer amount increases, but there is no clarity on how much better the rate gets and the improvement is not the same for all the banks surveyed. (Accourt, Bank charges on international payments, An analysis of the UK SME market)
Banks buy and sell currency at a certain buying/selling rate which is significantly more advantageous than that applied to their customers. Although we cannot forget the fees (sometimes quite hefty, up to £40 or more) the bulk of their revenues from international transfers come from the spread. (Accourt, Bank charges on international payments, An analysis of the UK SME market)
Summary of issues identified:
- Inefficient processes: The process of making cross-border payments is too cumbersome, unpredictable and it takes a long time to clear funds, which slows down the receipt of invoices and the opportunity to get early payment discounts. There are several steps involved in lengthy manual document verification. The solutions are fragmented with a number of touch points and interactions that slow down the process. This causes difficulties in tracking and reconciling end-to-end payments. (EY, #payments, insights, opinions. Volume 16, 2017)
- Lack of transparency: There is lack of transparency concerning the FX charges and high transaction costs which banks and other financial firms impose on cross-border transactions. While large corporations have been able to negotiate better terms and tend to be well-served by existing solutions, SMEs find themselves in a position where they are limited in finding the best solutions and have to deal with expensive terms for their cross-border transfers. (EY, #payments, insights, opinions. Volume 16, 2017)
- Limited infrastructure capabilities: Banks have long been reliant on the payment infrastructure that has been established over the years and that lacks modern capabilities and efficiencies. There are limited security controls in transferring funds and no capability to receive a large number of payments at the same time. These systems lack standardization and automation in interbank and intra-bank networks as a result of largely independent development. Emerging players have seized the opportunity to address these challenges and, leveraging technology capabilities, have developed solutions which are more convenient for customers. New entrants are reshaping global payments by adopting new technologies, offering businesses and consumers convenient solutions, and by encroaching on the traditional field of banking. These players are putting pressure on margins and tapping into consumer needs. Increasing numbers of nonbank players are entering the cross-border payments market, targeting the low-value payment segments because of high fees and lower entry barriers. The approach taken by banks for cross border payments through legacy models and fee structures is losing relevance, making banks rethink their strategy and consider partnerships with nonbank players. On the other hand, this market is placing greater emphasis on transparency and compliance, including better disclosure of foreign exchange fees, compliance with anti-money laundering (AML) laws and detailed transaction reporting. Modernizing infrastructure by adopting new technologies and making changes to legacy systems will allow payment players to offer better solutions to businesses and consumers looking for faster payments, digitization and integral solutions. (EY, #payments, insights, opinions. Volume 16, 2017)
- According to Money Mover UK SME International Payments Analysis:
- 80% of SMEs do not know the true cost of foreign exchange through their banks
- 43% of SMEs would find international trading more attractive if FX fees were more transparent
- Banks can charge upto 4% for money transfers
- International payments services from banks are extremely difficult to integrate into financial workflows providing SMEs with a major headache.
10.6 Customer journey prototypes
This section focuses on the customer experience of UC1 “Supplier Payments from invoicing (B2B)” and UC2 “eCommerce Goods and Services (C2B)”. These have been examined and developed into customer journeys and prototypes.
10.6.1 Example 1: Supplier Payments from invoicing – Hero (fictional company)
- Hero is a comprehensive accountancy package for SMEs supporting multiple aspects of managing a small business including accounts, payroll, advisory, expenses and invoicing
- Securely connecting Hero to your account provides a consolidated dashboard of company accounts with one or more banks and also lists of payables and receivables invoices
- SME can view individual invoice details including invoices from international suppliers

- Hero offer SME customers the option to use Open Banking for making international payments to suppliers allowing them to view the balance, FX rate and bank charges before selecting the bank account to use for the payment
- Furthermore, Hero allows SMEs to initiate international payments to pay these invoices pre-populating many of the required payment details directly from the invoice.
10.6.2 Example 1 Prototype:
SME payment journey:
https://invis.io/83F7GP1VU#/272021717_00_-_Hero_Login
This design enables the SME to initiate international payments directly from within their Hero accounting package. This is still a single payment and there is no reference to repeated payments or multiple payment submissions. The SME customer will be redirected to their ASPSP and will authenticate and authorize as per the existing single immediate payment journey.
10.6.3 Example 2: eCommerce – Cherry Watch (fictional company)

- Cherry is a company selling electronic goods online such as watches.
- Cherry is based abroad and will deliver goods to the UK.
- Payments to Cherry for purchases are expected in foreign currency (i.e. USD).
10.6.4 Example 2 Prototype:
eCommerce payment journey: https://projects.invisionapp.com/share/A9F6EDJU5#/screens/271685053
This prototype enables consumers to purchase goods online from a company based abroad, making the international payment for the purchase goods directly from their consumers bank account, using Open Banking.
10.7 Customer (PSU) research
Primary customer research performed by Ipsos, included 25 interviews in total:
- 15 consumer interviews and 10 SMEs interviews across London, Manchester and Birmingham
Findings from customer research highlighted the following key points:
- The prototyped customer journey used for customer testing was generally clear and straightforward. However, some customers would like something closer to Amazon One-click for secure devices, to avoid needing to re-authenticate every time.
- The Open Banking logo used for testing purposes worked well. It looks legitimate versus the wider mix of payment brands
- There is a general customer preference for the journey to display the FX rates and the bank charges before redirection to bank happens, as this offers greater transparency. Most customers, when prompted, agreed that this is not the case with other payment methods currently in use, for example credit cards.
- However, while highlighting rates and charges prior to redirection is preferred, both options would be acceptable from customers, i.e., when the FX rates were not shown on the retailers site on first view, customers were not asking for them.
- Those customers using credit cards for international payments have mentioned that they value the protection offered by credit cards, in case disputes arise. Customers asked questions if paying through Open Banking would offer similar protection if something went wrong. Customers were also asking to identify who would take the responsibility (the vendor, the ASPSP or Open Banking).
- A few customers spontaneously noticed the benefit of the ability to compare FX rates and charges between ASPSPs. Most customers reported not currently doing this, however it is a nice to have option if was simple to use.
- The limited period (e.g. 5 min) of holding time for the FX rates was spontaneously noticed by roughly 1/3rd of respondents. Some customers accepted this as they understood that FX rates fluctuate so they could accept the FX rated might only be guaranteed for a certain period of time (e.g. minutes only). In addition, most customers rationalised that currency would fluctuate little in a short period of time that any difference in the actual final rate would be marginal especially for small amounts. The limited time period was felt to be slightly pressurising, thus encouraging customers to rush through the process.
- Business customers viewed as very helpful or innovative, the extra option to be able to make international payments through their accountancy package.
- However, the mentioned that authentication for each invoice payment in the SME customer journey could be a barrier, especially in cases of multiple payments. They proposed a session login or daily login to expedite multiple payments.
Detailed findings from the customer research conducted by OBIE can be found in the attached report below:
10.8 International payments models and OBIE proposition
10.8.1 Model 1: International Payments through the ASPSP

10.8.2 Model 2: International Payments through a Remittance Service Provider

10.8.3 OBIE proposition
10.8.3.1 Basic Proposition Model
The OBIE proposition model is based on the OB Single Payment model through using a PISP for the payment initiation but extends the model and the specification to be able to support all the international payment requirements as per the PSD2/PSR regulations. The basic propositional model is shown below:
Note: This is only an example diagram. The proposition model also includes payments in non GBP accounts in the UK.
10.8.3.2 Additions to the Basic Model
In addition to the regulatory payment information requirements, the OBIE proposition may try to address some of the main issues with international payments identified from the market research. These include:
- Lack of transparency: The OBIE proposition requires the ASPSP to share FX rate to be used for the payment initiation with the TPP. Similarly, the proposition is requiring the ASPSP to provide to the TPP the bank charges that will be applied to the international payment. This way, it provides better transparency of the costs of the international payment
- Inefficient processes (too cumbersome): The proposition is addressing this issue though the PISP integration in the payment journey. PISP can prepopulate some information during payment setup thus reducing the information the PSU needs to provide to the ASPSP.
- Limited infrastructure capabilities: Although the proposition cannot solve the issue of the payment infrastructure capabilities, it does however trying to make it easier for the customer to understand the limitations by requiring the ASPSP to provide the cut-off times and expected value dates for the international payments.
- Difficult to integrate into financial workflows: The OBIE model through the PISP R/W capability allows international payments to be initiated directly from invoicing and accountancy packages and other software being used by SMEs, making it easier to integrate the process of international payments to the SME workflows.
Please refer to the high level requirements section 10.1
10.8.3.3 Value Proposition
- For PSUs:
- Allows SMEs and Consumers to initiate international payments directly from the bank account from a third party application (e.g. accountancy package) or from the eCommerce site during checkout.
- Provides customers with information on the FX conversion rate and the bank charges that are to be applied to their international payment
- For TPPs:
- Allows online shops based abroad to offer another payment method for customer to make payment
- Allows TPPs to offer international payments directly from budgeting and accountancy packages
- For Banks:
- Allows banks to capitalise further on their international payments infrastructure by allowing their customers to make international payments without using their online platform, thus increasing customer reach.
- Allows banks to further compete on FX rates and transaction charges for their multibank customers
- For OBIE:
- Completes the payment capabilities portfolio through enabling international payments, thus increasing potential adoption rates
- Allows OBIE to provide an improved channel to customers for making international payments.
10.8.3.4 Positioning
OBIE considers the main uses for the international payments to be the SME payments to businesses. This is because of the size of the market segments and also because the SME market is currently using the bank accounts to make those payments. The eCommerce use case has a lot of potential and will grow in size massively of the following years. OBIE is considering this to be a target use case with high potential; however, there are challenges that need to be addressed in order for the OBIE to be successful in this segment.
10.9 P20 Accounts in scope (current view)
Caveat: The below table is the current view of the P20 roadmap item and is subject to change due to future CRs.
Account Type | Description | AIS | PIS |
---|---|---|---|
Current accounts | Personal and business current accounts | Y | Y |
Payments enabled flexible savings accounts | Flexible Savings are instant access account which offer interest, where customer can put in or take out money whenever they like. Payments are made either to a linked current account (Post Office Money, AA) or to any other account (HSBC Flexible Saver) | Y | Y |
Payments enabled deposit accounts | Deposit accounts which allow initiation of payments from an online channel of the ASPSP | Y | Y |
Payments enabled loan accounts | Loan accounts which allow initiation of payments from an online channel of the ASPSP | Y | Y |
Payments enabled mortgage accounts | Current Account mortgages which combine customer’s mortgage and current account to give one overall balance. Customers can use these accounts to make payments from the online channel and some issuers will also issue a debit card | Y | Y |
e-money accounts | E-money accounts represent cash value that is stored in an account. Products supported by e-money accounts could be pre-paid accounts with virtual account number-sort codes, pre-paid cards. | Y | Y/N (depending of the e-money product) |
Credit card accounts | Credit card account is a payment account, which is available online, with the card issuing entity. For a PSU there could be multiple credit cards linked to the same card account (e.g. MBNA Visa and Amex cards linked to the same account) PSU could have have multiple card accounts (Visa, MasterCard) with the same issuer. A credit card is a credit facility that requires a repayment of a minimum amount each month | Y | N |
Charge card accounts | A charge card is a card that requires payment in full every month. A charge card is a credit facility that requires repayment of balance in full every month. | Y | N |
10.10 AML – Required bank details
In order to make an International Payment, the PSP will need some of the following details relating to the Beneficiary’s bank account:
Data Field | Description |
---|---|
The Account Holders Name | The recipient’s full name |
SWIFT/BIC Code | A SWIFT Code consists of 8 or 11 characters, both numbers and letters e.g. RFXLGB2L. |
Sort Code | UK Bank code (6 digits usually displayed as 3 pairs of numbers), optional if within EEA |
Routing Number | The American Bankers Association Number (consists of 9 digits) and is also called a ABA Routing Number |
Routing Code | Any other local Bank Code – e.g. BSB number in Australia and New Zealand (6 digits) |
IFSC Code | Indian Financial System Code, which is a unique 11-digit code that identifies the bank branch i.e. ICIC0001245. |
IBAN | The International Bank Account Number |
Bank Name | The name of the bank where the recipient’s account is held |
Bank Address | The address of the Beneficiary’s bank |
Account Number | The recipient’s bank account number |
Note: When IBAN/BIC are used, not mandatory to have a sort code for payment sent to UK in currency.
The information required is different for each country. For further information please see the table below:
Receiving Country | Currency | Information Required | Optional Information |
---|---|---|---|
UK | GBP | Account Holder’s Name | IBAN |
Account Number | SWIFT/BIC code | ||
Sort Code | |||
UK | All Other Currencies | Account Holder’s Name | Sort Code |
IBAN | |||
SWIFT/BIC code | |||
All European Countries | All Currencies | Account Holder’s Name | |
IBAN | |||
SWIFT/BIC code | |||
Hong Kong | USD, EUR, GBP | Account Holder’s Name | |
IBAN | |||
SWIFT/BIC code | |||
China | USD, EUR, GBP | Account Holder’s Name | |
Account Number | |||
SWIFT/BIC code | |||
Bank Name | |||
Bank Address |
Note: For payments in Euro the customer does not have to provide this, the sending bank must derive it from the beneficiary IBAN.Need to confirmIf that all banks can derive this form the IBAN.
Receiving Country | Currency | Information Required | Optional Information |
---|---|---|---|
Australia / New Zealand / South Africa | All Currencies | Account Holder’s Name | SWIFT/BIC code |
Account Number | |||
Routing Code | |||
Bank Name | |||
Bank Address | |||
Canada | All Currencies | Account Holder’s Name | Routing Code |
Account Number | |||
SWIFT/BIC code | |||
Bank Name | |||
Bank Address | |||
USA | All Currencies | Account Holder’s Name | SWIFT/BIC code |
Account Number | |||
ABA Number | |||
Bank Name | |||
Bank Address | |||
India | INR | Account Holder’s Name | SWIFT/BIC code |
Account Number | |||
IFSC Code | |||
Bank Name | |||
Bank Address | |||
India | All Other Currencies | Account Holder’s Name | IFSC Code |
Account Number | |||
SWIFT/BIC code | |||
Bank Name | |||
Bank Address | |||
All Other Countries | All Currencies | Account Holder’s Name | SWIFT/BIC code |
Account Number | |||
Bank Name | |||
Bank Address |
Note: Whilst the SWIFT BIC is required to route the payments, for payments in Euro the customer does not have to provide this, the sending bank must derive it from the beneficiary IBAN. Need to confirmIf that all banks can derive this form the IBAN.
10.11 Additional scope considerations
- International Payment transactions from UK sterling (GBP) accounts can be:
- Intra-EEA using EEA currency
- euro (€) currency transactions (executed within SEPA Zone):
- The 28 countries of the European Community (plus associated territories)
- The 3 European Economic Area (EEA) Member States (Iceland, Norway and Liechtenstein)
- Monaco, Switzerland and San Marino
- euro (€) currency transactions (executed within SEPA Zone):
- Intra-EEA using EEA currency
In addition, SEPA Instant Credit Transfer (SCT Inst) if supported by ASPSP
- Non-euro (€) currency transactions : Bulgarian Lev (BGN) – Bulgaria / Croatian Kuna (HRK) – Croatia / Czech Koruna (CZK) – Czech Republic / Danish Kroner (DKK) – Denmark / Hungarian Forint (HUF) – Hungary / Polish Zloty (PLN) – Poland / Romanian Leu (RON) – Romania / Swedish Kroner (SEK) – Sweden / Pound Sterling (GBP) – United Kingdom
Note that CHF is an EEA currency as it is official currency of Liechtenstein, although Switzerland is neither in the EU nor in the EEA.
b. Intra-EEA using non-EEA currency (any currency)
- Electronic payments made in any other currency of an EEA State where the Payer’s PSP and the Payee’s PSP are based inside of EEA.
c. One Leg Out (any currency)
- Electronic payments made in any other currency where the Payer’s PSP is based inside of EEA and the Payee’s PSP is outside the EEA.
- One-leg Out using EEA currency: EEA currency sent from the EEA to a non-EEA country (with or without currency conversion) e.g. EUR payment from UK to Japan or CHF from UK to Switzerland.
- One-leg Out using non-EEA currency: Non-EEA currency sent from the EEA to a non-EEA country (with or without currency conversion) e.g. USD payment from UK to USA.
2. International Payment Types to be supported by Open Banking
Payments initiated by PISPs using Open Banking Write APIs, should be able to cover payments to be executed under the following international payment types:
- SEPA Credit Transfer (single payment)
- SEPA Instant Credit Transfer
- SEPA Credit Transfer (bulk payments in alignment with roadmap item P11)
- Correspondent payments / SWIFT Payments – Single Customer Credit Transfer MT103 (single payment)
- RTGS on Target2
- EBA Euro1
- International transfers (PSU’s domestic account to PSU’s overseas account)
- Currency account transfers (i.e. IATs in currency)
- TBC (any more to be confirmed)
3. Charge Models
Payments initiated by PISPs using Open Banking Write APIs, should be able to cover the following international payments charge models:
- “SHARE” transfer: The sender PSU of the payment will pay fees to the sending bank for the outgoing transfer charges. The receiver PSU will receive the amount transferred, minus the correspondent (intermediary) bank charges.
- “OUR” transfer: All fees will be charged to the sender PSU of the payment – i.e. the receiver PSU gets the full amount sent by the sender of the payment. Any charges applied by the receiving bank will be billed to the sender of the payment (usually sometime after sending the payment)
- “BEN” transfer: BEN (beneficiary) means that the sender PSU of the payments does not pay any charges.. The receiver PSU of the payment receives the payment minus all transfer charges, including the sending bank charges if any.