FAQs

Your questions answered

To help you better understand Request to Pay, we have developed some frequently asked questions. If you have any further questions or would like to discuss how to get involved in Request to Pay, email info@requesttopay.co.uk.

We expect there to be sufficient capacity created in the market during H1 2021. The banks will certainly help with scaling up Request to Pay, but there are other providers that could get involved to increase access.

Since publication of the Framework at the end of May 2020, we have enrolled a service provider and a technical provider. These are listed on our website. We are also working with a number of other companies who are currently progressing their solution and expect to announce further new joiners in the coming months.

Any financially regulated organisation with a large customer base could certainly help adoption, such as the high street banks, but also comparison websites or other technology-based providers who meet the eligibility criteria could assist.

We are discussing this with the banks at present and hope to see them starting development in the new year. One of the purposes of the webinar was to highlight the demand for Request to Pay.

The design of the Framework is to encourage innovation. So Fintechs can build either apps or repositories, or both.

In order for payers to have confidence that the billers are legitimate, we require that Service Providers are FCA or PSR authorised so that we can be confident that appropriate AML and KYC controls are in place when on-boarding end users. Most billers will not be FCA or PSR authorised. Also the App Service Providers need to be able to offer at least two methods for the end user to pay all requests, which won’t necessarily be from the biller.

We are continually having conversations with government departments and in principle they are very supportive of Request to Pay and many of the departments can see lots of use cases for Request to Pay.  However, to date we have not spoken to them about vulnerable communities, but this is something we are planning on doing in the near future.

Request to Pay provides a secure digital method to send a request that relates to a bill. It has been designed to give the consumer control of how they pay the request. However, the commercial arrangement is a matter between the supplier and their customer.

It includes those on pre-pay meters.

We do not support split bill functionality. Request to Pay is the means of securely presenting a bill request to someone. It does not impact on the commercial relationship between the two parties. How their payments impact credit scores is out of scope of the Request to Pay Framework and provided the request is paid by the due date it should not have any impact.

Yes, it is payment agnostic.

No Request to Pay is a secure message service. However, it does allow the consumer to pay in the way that suits them, provided the biller accepts that payment type.

Our rules require that apps are developed to allow the end user to access multiple accounts on multiple repositories. This works in the same way that an email app on your phone today allows you to see all of your email accounts in one place.

Not necessarily, this is down to the competitive design of the app provider. They may use Open Banking which could interact with the end users bank, or they may offer payments through another service e.g. PayPal.

Apps have to allow the end user to log into all of the accounts that the user has.

This has been at the heart of the design of Request to Pay. This is why the Providers have to be authorised by the FCA / PSR and need to perform KYC checks when on-boarding an end user. There is also the need for a Pre-authorisation message to be sent from the biller to the payer before any Requests can be sent. This provides the Payer with the opportunity to decline the relationship if they don’t recognise it. Finally, the Payer has the option to decline a request and block future requests if they don’t want continue using Request to Pay with the Biller. when this happens, a message is sent back to the biller informing them, so that they can make alternative arrangements.

Request to Pay is a Framework, the companies who adopt it and build it into their propositions will want to promote their products. However, to help with end user identification of who is part of the Request to Pay Framework, we have created an Indicator Mark to show compatibility, similar to the contactless or USB logos.

Part of the Mark Guidelines Toolkit will be to help organisations who are developing Request to Pay propositions to help provide elements of education about the Mark and what it means, but also how Request to Pay will operate and how it can help individuals manage their finances and have more control over how and when they pay their bills. It should also be noted that those organisations who join the Request to Pay Framework also have a responsibility to educate their customers, and if we work together as a Request to Pay community we should be able to use Request to Pay to help people understand more how they can better manage their finances.

Request to Pay is already taking off around the world. We have been talking to the EBA / EBC, Canada, US, Australia, P27, Vietnam amongst others about their plans and implementation of Request to Pay propositions. The Nordics have been running Request to Pay services for several years.

Regarding Standards, we have aligned our messages as far as possible to ISO 20022. However, to address the consumer control detriments we needed to add more functionality which led us to extend are message standards. We have included the International payment fields to aid compatibility and the messages can be extended to carry additional payloads for other markets. This includes the capability to include BIC and IBANs.

The Request to Pay standards have been designed around ISO 20022. Common fields are named the same and have the same definition to assist with translation to Pain.001 and Pacs.008. We are also talking with other Request to Pay Frameworks Internationally and will continue to work with them as the standards evolve. We believe that as a messaging system, the Framework should be Payment Agnostic and should be capable of working across border.

Request to Pay does not affect the commercial arrangements between the Biller and the Payer. It simply carries the Request message including details of how to pay it. At launch it is intended that Request to Pay should be limited to the UK, Northern Ireland and the Channel Islands, but further expansion to other territories in the future is certainly possible.

There are a lot of similarities, but the EPC/SEPA offering is based in Pain.013/014 messaging and is tied to SEPA as a payment type. Also because of the limitations of Pain.013/014, they don’t offer the consumer control of partial and full payment or requesting a revised due date.

Both the Point of Sale Proposal and International Request are still a work in progress and as such there are not too many details that we can provide at this present time, apart from the fact that it is something we will be looking at developing in the not too distant future.  If anyone would like to provide input into these developments please get in touch.

This is certainly possible and we are talking to organisations to also allow a Request to be settled in cash through their outlets. The Point of Sale Use Case is something we are looking to develop in the near future.

The cost card for Request to Pay is available on our website.

Afterpay / Klarna are types of services that could use Request to Pay to settle the original Request and then could use Request to Pay to request the subsequent repayments.

You would have to ask HMRC that. However, we are talking to HMRC and Government Banking about Request to Pay.