ACCOUNT. PAYMENTS.

The explanations in this section are based on the general introduction to the  transaction model and to the 4 party model on. The following information will focus on, the peculiarities of account-based payments.


ACCOUNT PAYMENT IDENTIFICATION

The identification for account payments takes place digitally by registering in online banking, employing an access code that is assigned to a specific account. On a remittance slip, identification is carried out by entering the name of the payee and the IBAN.


The payer's IBAN is required for taking direct debits. The payer's IBAN may be provided via a debit order issued by the payer. Another option consists in consulting the SEPA proxy lookup which is available in the SEPA area.


IDENTIFICATION FOR ACCOUNT PAYMENTS VIA SEPA PROXY LOOKUP (SPL)

Electronic payment transactions are now standardized throughout Europe using the IBAN. In (mobile/digital) payment transactions, the entry of the IBAN by the payer is an obstacle to the convenient execution of payment transactions and the secure identification of the payee.

The SPL scheme makes it possible to pay across Europe using a uniform proxy.

In addition to a set of rules, a uniform standard and their data formats, SPL provides a (chargeable) independent service (with costs) for registered service providers. As an addition to existing SEPA services, SPL improves their applicability and user-friendliness. It also provides the basis for new use cases at European level.


BACKGROUND TO IDENTIFICATION WITH THE SEPA PROXY LOOKUP (SPL)

A proxy is an intermediary or, in the case of the SPL, a mechanism that accepts requests from an address (e.g. mobile number) for mediation and enables a connection to the other side using its own data (e.g. IBAN). In the SPL scheme, this mechanism is used for clear payer identification. The SPL proxy is both technically and organizationally independent of a payment method.

Therefore SPL is an essential element for implementing person-to-person (P2P) or other payment methods (e.g. SCT or payment cards) in a user-friendly app-based manner. In the first step, the mobile number or e-mail address is provided as a proxy, as is already known from messenger apps. But other proxies are also conceivable and should be specified in the next step.

This means that the sometimes complex and error-prone transfer of sensitive payment data, such as e.g. B. the IBAN or the credit card number, can be simplified when initiating the payment. SPL can thus contribute to interoperability for the exchange of necessary data in payment transactions.

Account data can also be exchanged in this way for non-IBAN-based processes such as some P2P processes.

The aim is to establish a uniform standard for various payment methods in Europe: mobile, digital and convenient.

SPL focuses on the payer's search function (so-called lookup function) in order to initiate a subsequent payment. The actual payment is not part of the SPL scheme, but is covered by existing payment methods. The SPL scheme or the corresponding service provider of the procedure acts as an intermediary to ensure the processing of the SPL requests and responses.



More about SEPA PROXY LOOKUP.

INITIATION OF ACCOUNT PAYMENTS WITH REQUEST TO PAY (RTP)

Immediately after identification, the RtP initiates  a payment process.

Request-to-Pay (R2P) is a new "European" standard for payment requests that, as an upstream communication channel, can complement and thus simplify existing payment instruments.1

R2P simply defines rules and technical elements that enable a payee to request a sum of money in EURO from a payer for a specific business transaction. The primary payment instrument for the payment itself is currently the SEPA transfer (SCT/SCT Inst).

Fig.: RtP process components in context


The RTP is explicitly not a new payment instrument, but an additional preceding level of communication (= request layer) between the parties involved (primarily payee and payer).

Fig.: Main participants in the RtP process


The payee transmits to the payer:

  • bank account information,
  • note to payee,
  • amount in EURO to be paid, and
  • the payment instrument the payee requests to receive the payment with (e.g. SEPA Instant Payments).

The R2P notification and interaction between the actors is immediate, e.g. B. via the banking app. The payer may either accept or decline the R2P.  Once the payer accepts the R2P, the payment will be initiated and will not be able to be refused.

The processing of the R2P offers a wide range of applicabilities:

  • Digitized invoicing (purchase) processes (e-invoice or regular invoicing process)
  • In e-commerce websites during check-out (wallet/remote payment)
  • In physical stores at the POS terminal or other POIs
  • Cash remittances between two person (P2P payments)
  • Recurrent orders of direct debit ( e.g. utility companies, tax authorities)

Depending on which area the R2P is used for, vari-ous methods can be applied in order to initiate an R2P (e.g. NFC in the area of POS or QR-code based applications in e-commerce.


1 Currently, 27 credit institutions in Europe support the R2P initiative via the EBA infrastructure.

 


 More about Request-to-Pay.

ACCOUNT PAYMENT AUTHENTICATION

The authentication for account payments is in alignment with the specifications of the PSD2 described above. Unlike in the process employed with card payments, in account payments there is no need for interoperability in authentication. The payer's bank is therefore free to design the authentication process within the respective regulatory framework. This results in authentication media and processes being more versatile.


However, logging into online banking does not meet the requirements for strong authentication. To that effect, an additional authentication tool needs to be employed; otherwise an individual payment must be released from the required strong authentication by using one of the designated exceptions.


DISPOSITION/AUTHORIZATION OF ACCOUNT PAYMENTS

In account payments, authorization and disposition do not necessarily take place at the same time. This may result in downstream processes leading to the execution of the payment.

As an example, direct debits may, be returned. Direct debit returns may occur due to insufficient account funds, incorrect data and unauthorized debits. Returns are triggered partly automatically and in part by an account manager.

The disposition may determine which of several direct debits is/are returned.


ACCOUNT PAYMENT CLEARING/SETTLEMENT


ACCOUNT PAYMENT BILLING


CLAIMS IN ACCOUNT PAYMENTS


Should a claim about an account payment be placed, the payment method used in the transaction is decisive. Transfers initiated by the payer, eg SEPA Credit Transfer (SCT), are binding for the payer and his institute once they are executed.


Direct debits initiated by the payee, eg SEPA Direct Debit (SDD), can be claimed by the payer without giving any specific reason. When returning direct debits, deadlines have to be observed. A return of payment does not require the transaction which the payment is based on to be reversed.


Likewise, incorrect execution by the payment service provider, e.g. the double execution of orders or the incorrect manual processing of a document,may provide grounds for placing a claim. In this case, the claim is to be settled between the customer and his institute. The institute may then, if necessary, resort to the second party in the payment process for settlement of claims.