Identification Mechanisms

BIC and IBAN

The issue of addressing in a messaging service is based on the sharing of the identifiers. SEPAmail provides a two-fold solution based on a business vision and not a technical point of view.

• As ensuring the security of the messaging system seems to be more suitable via the banks, the BIC is the identifier of the “SEPAmail access provider”.
• The identifier for the bank’s customer can be chosen among several possibilities (account Id, card number, dedicated online banking identifier), but given the position of SEPA and the promises of payment services makes it obvious that the (pan-European) IBAN is the best choice.

Even if the acronym ' ' IBAN@BIC' ' is used, it only corresponds to a ' ' 'business' ' ' approach and not to a technical view. From a business point of view:

• The BIC, which is the bank’s identifier, is not sensitive data and transits in unencrypted form
• The IBAN, which is the customer’s identifier, is by definition sensitive data and must be protected. It can only be transported in a protected format.

BIC – Customer Constraints

In addition, the first testing phase with SFR highlighted the following:

• The creditor can easily find the IBAN by using the BBAN (customer account Id) and a well-known algorithm.
• There is no reliable method allowing the creditor to consistently find the BIC.

Given the market reality, the anticipated regulatory pressure and the projected customer-bank use of the SEPAmail standard, SEPAmail has proposed not to oblige customers to provide a BIC but only an IBAN. The SEPAmail bank is then responsible for providing enhancement.

Non-Fixed Identification

From the outset of SEPAmail, the standards and implementation teams have made a concerted effort not to solidify the use of the BIC and IBAN to be able to use other types of identification which could serve to meet complementary needs outside the scope of SEPA. In the context of SEPA, the IBAN only covers payments by credit transfer and direct debit.

More generally, any identification of the type ' ' ' identifier@bic' ' ' may be useful for SEPAmail. This characteristic, in addition to the previously mentioned notion of enhancement, enables SEPAmail to provide a wide range of identifiers.

PAN-based Identification: Primary Account Number, or simply Card Number

The card number is an identifier which is at least as well-known as the IBAN, if not more. It also has the advantage of often being present with the customer – the cardholder – more often than the Bank Account Identity statement!

The PAN can easily be used to:

• Identify the BIN (Bank Identification Number) from the PAN. In most cases, the first 6 characters are enough to do so.
• Associate the BIC with the BIN. This is done by using the ' ' List of Institutions' ' (fichier des établissements) managed by Cartes Bancaires or by other organizations for other European countries.
• Format SEPAmail transmissions with:
  • the BIC and the PAN; the latter replaces the IBAN to identify the receiving customer
  • the BIC and the IBAN for the sending customer
• Associate, at the receiving bank, the PAN with either the IBAN or the customer’s account references. By definition, any card issuer knows how to associate a card number with an account number, if only to debit its customer!

The PAN could be used to extend payment notifications to card payments: JADE for cards!

QXBAN – a SEPAmail Identification

Even though the IBAN is becoming commonly used, there is a security issue as it is a sensitive piece of customer data. It can be used by some fraudsters, either as a means of identification with a call centre not enough vigilant regarding authentication procedures, or to generate direct debits, including some without prior authorization.

During the RUBIS and SAPPHIRE testing, the following constraints appeared:

• it is not acceptable to directly provide the creditor with the IBAN
  • It is difficult to promote the use of the IBAN with customers whose main concern is not to communicate their IBAN and who therefore continue to use cheques (as direct debits require the use of the IBAN)
  • The sensitivity of a creditors database increases when IBAN numbers are added to it
• It is not practical for two consumers to exchange an IBAN.

SEPAmail therefore created the QXBAN:

• a format very close to the IBAN in order to remain compatible with SEPAmail developments and standards
• cannot be used for clearing purposes, therefore account debits are not possible
• non user-friendly (due to a great number of characters) to avoid being used in authentication procedures
• exclusively used with SEPAmail network

The format of QXBAN ' ' 'nearly' ' ' complies with the IBAN standard, but has a few special characteristics: •the country code is ' ' 'QX' ' ' – this is the only element which is NON-COMPLIANT with the IBAN standard. As a QX country code does not exist, no clearing can occur with such a code. •the bank code ' ' 'MUST' ' ' be the bank’s BIC or at the very least the SEPAmail routing code of flows •the account number ' ' 'MUST' ' ' be randomly selected under the responsibility of the customer’s bank •the account number ' ' 'MUST' ' ' have the maximum length of characters in order to increase the randomness of the QXBAN.

QXBAN format – needless to say, the bank which has issued a QXBAN undertakes to receive and process it and therefore to organise the internal correspondence between the QXBAN and the customer’s IBAN.

Here is the algorithm used for QXBAN generation

SEPAmail Bank Account Identity: RIS2D

An interesting synergy emerged between the work on QXBAN and the 2D-DOC project. This resulted in the creation of the notion of RIS2D or SEPAmail Bank Account Identity. Its characteristics are:

• the same logic as a Bank Account Identity statement, but adapted to the identification of a “SEPAmail account”.
• created in the form of a 2D barcode both to facilitate the reading of the code and the processing of the high number of characters.

The RIS2D includes the LAST NAME, FIRST NAME, QXBAN and a signature for these data elements in the 2D-DOC format.

' ' 'There are no plans to represent the SEPAmail Bank Account Identity other than in the RIS2D format' ' '.

In addition to the barcode, the format includes the following:

• stars which represent the SEPAmail logo
• a partial unprotected presentation of the first name and last name for purposes of clarity.

Protection of Identifiers for Payments by Credit Transfer

The diagram below shows how it is possible to avoid communicating an IBAN for payment by credit transfers and therefore to protect this sensitive data.

1. When registering its customer for this service, the customer’s bank generates the QXBAN, maintains the database {QXBAN->IBAN} and gives it to the customer in the form of a RIS2D (section 1)
2. The customer is then free to provide the creditor with this easy-to-read image from which the creditor can extract the QXBAN, last name and first name (section 2)
3. The creditor can start the sequence for a payment request only by using its customer’s QXBAN (blue flow line)
4. The bank which receives the request is able to identify its customer thanks to its {QXBAN->IBAN} database (section 4) and can offer its customer the validation service. It should be noted that any of the customer’s accounts can be debited if the bank provides this service.
5. The return flow (red flow line) is performed using the debtor’s (customer) QXBAN.
6. The transfer uses the ordering party’s IBAN. However, this IBAN remains within the environment of the creditor’s bank as the latter is not authorized to communicate the IBAN of the ordering party to a beneficiary.

Protection of Identifiers for payment by direct debit

There is an issue regarding payment by direct debit due to the obligation to provide an IBAN to the creditor. Using the identifiers (RIS2D-QXBAN) and SEPAmail flows could be a way to bypass this constraint. Indeed, the SEPA DIRECT DEBIT standard imposes a Unique Mandate Reference (UMR) which can be used advantageously for this situation.

1. As above, the creditor’s bank generated and provided a RIS2D (section 1)
2. The debtor customer provides its RIS2D or QXBAN to the creditor and requests a payment by direct debit. It should be noted that this might encourage more customers to adopt this type of payment.
3. The creditor generates a mandate request with the GEMME@SEPAMAIL service using the QXBAN and UMR - Unique Mandate Reference (blue flow line)
4. The debtor’s bank identifies its customer using the {QXBAN->IBAN} database, asks the customer to select the account it wants to be debited and sends back the direct debit mandate (red flow line) which was accepted by its customer along with the customer’s real IBAN. Concurrently, the debtor’s bank memorizes the UMR accepted by its customer and manages its validity.
5. The creditor’s bank creates a database {creditor/UMR -> IBAN} and indicates to its creditor customer that the mandate has been accepted.
6. The creditor now only needs to provide the UMR as a payment identifier in its direct debit initiation files (black flow line)
7. The creditor’s bank completes the UMR with the IBAN, which is located in the {creditor/UMR -> IBAN} database, and performs a clearing operation.

As a result, the sensitive identifiers (IBAN) remain in the banking environment to better protect the customers and to simplify the creditor’s management.

In addition, the above mechanism does not create a strong link between the creditor’s bank and the creditor. The latter can change banks quite easily:

1. The creditor sends the mandate amendments using the QXBAN/UMR pair and goes through the new bank
2. The debtor’s bank can respond immediately without any required validation by the debtor as this is an amendment
3. The creditor’s new bank creates the {creditor/UMR -> IBAN} database and will then be able to complete the direct debit flows

ICQX

ICQX is an identifier for legal persons participating in SEPAmail. The standard for ICQX is derived from the SEPA Creditor Identifier standard.