We’re ready for PSD2

Card Brand Compliance associated with Strong Customer Authentication

To support the roll-out of EMV 3D Secure technology, there will be programmes throughout 2020 to help with the compliance of card brands - such as Visa and Mastercard.  These are to make sure that all eCommerce payments processed in the European Economic Area meet the required Strong Customer Authentication (SCA) by 31 December 2020, as part of the Payment Services Directive 2 (PSD2). SCA aims to drive down fraud and improve confidence in card payments, allowing that growing sector to continue to flourish.

It is vital you actively manage your PSD2 compliance and monitor timelines for implementation.  You must have plans in place to operate to the highest version available of EMV 3D Secure. Card brand schemes, acquirers and gateways may well impose earlier deadlines to progress changes in good time to meet the official deadline.

Act now to gain certification and avoid penalties. For example transactions at devices with no Chip and PIN capability [Magnetic swipe] and those that are completed by manually entering the card details when the cardholder is present [Pan Key Entry] will incur fees for the use of these less secure payment methods in card present environments - whether excluded from the scope of PSD2 or not, i.e. Transit.  There is cost associated with the introduction of PSD2, but the greatest cost will be loss of sales, as failure to comply will result in declined transactions. 

Don’t forget the additional benefits to EMV 3D Secure: such as improved security, wider interoperability and flexibility to enable innovation, fewer barriers to market and greater choice to the consumer. 

We will provide further updates on the impact to your business in our monthly Card Scheme Changes bulletin, and within our series of PSD2 updates. To discuss how you can mitigate those fees and amend your strategy to take best advantage of the changes, talk to us today.

Have you ever wondered why MIT is always COF, but not all COF is MIT, and that you don’t need either if you do CIT, but if you do want to COF and MIT you will need a CIT first anyway?

Probably Not. You have better things to do. But your customers will love your business for knowing the difference.

We’re going to break it all down for you so that you can play your part in ensuring a frictionless payments flow for your customers while at the same time putting you in control of where the liability sits in the event of fraud. If you want to minimise the impacts of PSD2 SCA regulation soon to come into force across Europe, it’s going to be worth your while understanding these concepts and making sure that all of your customer payment pathways are compliant with the card scheme frameworks and the fast approaching enforcement of PSD2 SCA regulations[i].

Why do PSD2 SCA regulations make these transaction types and frameworks so relevant?

The new security regulations being introduced across Europe are aimed at reducing growing fraud by introducing Strong Customer Authentication (SCA), particularly in the virtual or e-commerce environment. SCA is already enabled in most physical POS systems across Europe via the use of Chip & PIN transactions. It has proven extremely effective in reducing common fraud scenarios.

That same level of cardholder and merchant security delivered by Chip & PIN in the physical space is now being mandated in the remote e-commerce channels. It is inevitable that with the benefits of increased security requirements, there is often a risk of smooth customer payment processes being threatened by the introduction of friction. We all want our customer payment experiences to be as frictionless as possible, avoiding card abandonment, increasing transaction approval rates and optimising sales while at the same time protecting the payments environment and ourselves, as both consumers and merchants, from fraudsters.

Remember that exceptions to, and exemptions from the need to perform SCA are available only in limited and strictly controlled circumstances. Otherwise, by law Issuers will now be required to challenge (step-up) all electronic transactions to SCA that arrive for authorisation approval but without proof that authentication has previously taken place.   

The use of the transaction frameworks we are about to describe are going to be key to your ability to continue to provide those frictionless flows that we enjoy today, securely, well into the future and all in compliance the European laws, the card scheme rules and your obligations as a user of the payment systems networks that support your business.

Key principles of PSD2 SCA – a quick re-cap before we start.

SCA fundamentals are well documented elsewhere on this website but just a few key reminders will help you to navigate your options as you consider implementing any of the customer engagement and payment transaction frameworks. 

• The intent of the PSD2 SCA regulation is to secure ALL electronic transactions, in ALL channels, with SCA.  Very few and limited exceptions to this rule exist. 
• This SCA means EMV Chip & PIN or Contactless in your physical sales outlets. In the e-commerce channels the most widely available authentication technology will be provided by EMV 3DS.
• As a general guideline, if the customer is ‘in-session’, present, connected on-line or in-store and therefore able to accept an authentication challenge request from their card issuing bank in real time, then they MUST be authenticated.
• Similarly, if the customer is not ‘in-session’ and not present, an authentication challenge request from their card issuing bank CANNOT be responded to. Therefore some transaction types have been considered either exempt from authentication, or out of scope of the regulation altogether.
• ‘In-session’ transactions, when authenticated, will shift fraud liability away from you.
• ‘Out-of-session transactions’ when not authenticated, will shift fraud liability towards you.

You’re going to have choices to make about:

• How you continue or modify your engagement with your customers on first contact.
• How you establish transaction processing procedures with them via consents and permissions supported by T&C agreements.
• How you will balance the desire for frictionless flows with the risk of fraud liability shifts that will result from your decisions.  

What is CIT, COF and MIT?

The payment transaction concepts are quite simple. However, the implementation of the framework can be a challenge as each card brand has a slightly different set of transaction types, guidance and requirements and the terminology varies a little between schemes, so let’s start by getting things defined for you.

CIT – Cardholder Initiation Transactions

This refers to any transaction where the cardholder actively participates in the transaction as it happens. We’re calling that ‘in-session’ and it applies to both Cardholder Present (Chip & PIN in your POS terminal) and Cardholder Not Present transactions (shopping on-line via web or app).

As per the key PSD2 SCA principles above, the cardholder is ‘in-session’ and must be authenticated, issuer approvals shift the fraud liability away from you. Typically a friction flow but frictionless flow can be enabled at Issuer discretion.

COF – Credential on File Transactions

Also known as Card on File, this refers to any transaction where the cardholder has previously stored their payment card credentials with you for ease of use in future transactions. Once a COF transaction has been performed, any future CIT transactions can use this COF framework to simplify the payment experience. The cardholder can inform you to ‘Use my saved details’ and avoid re-entering payment information for subsequent purchases. COF alone doesn’t determine liability shift. Frictionless flow may or may not be available. This is because COF can be used for both CIT and MIT transactions and it’s this latter type that reveals the real benefit of COF enablement - it enables MITs to be performed when the cardholder is not actively participating in future transactions.

MIT – Merchant Initiated Transactions

This refers to any transaction where the cardholder does NOT actively participate in the transaction, but is allowing you to generate transactions on their behalf via a prior consent agreement with you.

As per key PSD2 SCA principles, the cardholder is not ‘in-session’, cannot be authenticated again in real time, issuer approvals will shift fraud liability towards you. Frictionless flow results.

MIT transactions are only generated by the merchant, without the cardholder ‘in-session’ therefore if SCA is applied to these transactions it will fail. With no cardholder available to authenticate, these transaction types are one of the few considered to be Out Of Scope of the PSD2 SCA regulations.

Be warned. There are strict rules around the use of each transaction type and failure to follow the set-up requirements of each, as well as correctly flag your transactions for the same WILL result in transactions being declined or abandoned, ultimately leading to lost sales.

MIT transactions can only be used where an initial CIT has taken place (authenticating the cardholder and enabling COF in the first instance) and then using those credentials and the cardholder’s prior agreement via T&C’s to establish an MIT agreement with their Card Issuing bank. In all cases, a MIT must refer to the cardholder’s original interaction and authentication results. Each subsequent MIT submitted will be indicating to the card Issuer that the authentication process has already been completed and that this transaction is just a further MIT in a previously agreed, authenticated and approved series.

Who can make use of these customer engagement and transaction frameworks to avoid friction?  

Without doubt, merchants of all shapes and sizes can benefit from the convenience of enabling COF capability for your customers to generate loyalty and simplify payments. COF can be used when the cardholder is ‘in-session’ (CIT) or not ‘in-session’ (MIT).

The combined approaches of using CIT, COF and MIT provides for a generous mix of transaction and consumer journey types across a wide range of merchant types and payment processes, all compliant with PSD2 SCA regulations - provided that the required MIT frameworks are established, transactions are correctly flagged to Issuers, and that cardholder consents are obtained.

The MIT framework varies slightly between card brands but it is comprehensive, catering for a wide range of transaction processing scenarios. Categories of common ‘standing instruction’ MITs are available to enable recurring payments, instalment transactions and unscheduled COF events and journeys.

Also defined within the MIT framework are several ‘industry-specific’ MITs which enable merchants to fulfil a new or existing business practice – following up to an original cardholder interaction that could not be completed in one single transaction. Your options here will include incremental authorisations, re-submissions, re-authorisations, applying delayed and ‘No Show’ charges according to your cancellation policies.

The MIT transaction framework is relevant to all forms of e-commerce but is particularly important to the travel and hospitality sector which relies upon the need to post charges to cardholder accounts before, during and after the provision of goods and services, typically when the cardholder is no longer ‘in-session’. These concepts are fundamental to this sector so next month we will focus our post on this topic in more detail.

For now, here a just few potential transaction use-cases where the application of CIT, COF and MIT can be used to create a frictionless flow and maintain compliance with the regulations:

• Recurring payments  - creating a series of transactions for the same amount such as a subscription or membership service
• Instalment or pre-payments – enabling the cardholder to spread the cost of a larger purchase
• Incremental authorisations – where cardholder spend exceeds a previously authorised amount
• Delayed Charges – enabling you to post supplemental account charges after the original services have been rendered.
• No Shows – where the merchant is enabled to charge for services for which the cardholder entered into an agreement to purchase, however did not meet the terms of the agreement.
• Re-authorisations – a purchase made after the original transaction to include scenarios like delayed/split shipments or extended stays/rentals.

Business requirements for processing COF and MIT transactions  

Strict enforcement of PSD2 SCA regulation will be matched by equally strong card brand regulation, monitoring the correct use of MITs and other Out Of Scope exceptions and exemptions to SCA. Ensuring that transaction frameworks are correctly established in the first place requires business procedures as well as technology alignment to guarantee Issuer acceptance and approvals.

Incorrect establishment of agreements, incorrect flagging of effective transactions or miss-use of the framework in any way will result in transaction declines and lost sales.

COF processing requirements

Merchants offering cardholders the opportunity to store their credentials on file must obtain the cardholder's consent, therefore you will need to establish and maintain an agreement (T&C’s).

• Inform the cardholder that credentials are being stored, specifying how the cardholder will be notified of any changes to the consent agreement, and identifying the agreement expiration date.
• Disclose to cardholders how those credentials will be used.
• Notify the cardholder of the identity and location of the merchant and the transaction amount or how it will be calculated.
• The frequency (recurring) or event (unscheduled COF) that will prompt any transactions.
• For installment payments, the total purchase price and terms of future payments including the dates, amounts, and currency.
• Notify the cardholder when any changes are made to the terms of use.
• Notify the cardholder of any cancellation or refund policies.
• Retain the agreement for the duration of the consent and provide it to the issuer upon request.
• Where required by applicable laws or regulations, provide a record of the consent to the cardholder.
• Inform the issuer via a transaction that credentials have been stored on file.
• Identify and flag transactions with appropriate indicators when using stored credentials.

MIT processing requirements

Enabling Merchant initiated Transactions depends upon many of the same consent and cardholder disclosures that are required under COF, which is always a pre-requisite to processing a MIT.

The MIT framework was designed to provide Card Issuers (both authenticator and approver) with more transaction context enabling them to make better informed decisions and minimise unnecessary declines.

The framework allows Issuers to identity the intent of the MIT through the use of appropriate identifiers (message reason codes). Use of the framework also provides a proof of a preceding transaction by creating a linkage with it using a unique (Transaction Identifier) of the previous or original transaction.

Merchants must link the MIT with the original transaction using a unique Transaction Identifier that was generated for the original CIT. For certain MIT types, (recurring, instalment and unscheduled COF which are all also known as ‘standing instruction’ MITs.) the Transaction Identifier generated for the previous transaction in the series can be used to link the subsequent transaction.   

COF and MIT processing fundamentals – establishing frameworks

COF – when capturing a stored credential for the first time, in addition to the business processing requirements already listed, merchants will need to:

• Submit a payment transaction (authorisation) at the time of credential capture if an amount is due to be processed at the same time. If no amount is due at the time of credential capture, the merchant (or its agent when 3^rd party bookers are involved) must submit a zero-value authorisation (ZVA refers to Account Verification Authorisation by Visa, Account Status Inquiry by Mastercard).  Note that this is already an existing requirement for instalment and recurring transactions in the European region that rely upon COF.
• Identify in the transaction that the credential is being stored. Note that if either of the first payment transaction or the ZVA is declined, the credential cannot be stored and the merchant must not use the credential for any subsequent transactions.
• Note that an Issuer will not decline a transaction based on a missing CVV2 if the authorisation request is for a subsequent transaction after the credential is stored. This rule previously applied only to recurring transactions but is now applicable to Recurring, Instalment, Unscheduled COF and any transactions initiated by the cardholder (CIT) using COF

The story so far…  CIT creates COF and enables MIT resulting in frictionless payment flows for your customers.

So now we can go back and answer the questions in the very first sentence of this post.

MIT is always COF – For you to be able to generate a payment transaction when the cardholder is not in session (MIT), you’re going to need the cardholder details to have been stored beforehand (COF). The cardholder cannot be authenticated because they are not ‘in session’

Not all COF are MIT – If the cardholder visits your store in person or on-line, they can ask you to use their stored details (COF).  This in not MIT (no authentication required) but instead CIT (authentication must be performed as the cardholder is ‘in session’).

You don’t need either if you do CIT – by definition, if you are not using stored credentials (COF), you can’t initiate the transaction yourself (MIT), so the cardholder will have to be ‘in-session’ and authenticated each time (CIT) 

But if you do want to COF and MIT you will need a CIT first anyway? – SCA is mandatory whenever a credential is first stored in your systems (COF), and also MIT agreements can only be established after a successful authentication on the very first transaction in a series. The only way that the initial authentication can take place is when the cardholder is ‘in-session’ (CIT).

The story continues next month  

The accurate use of COF and the MIT framework is key to minimising friction, avoiding declines and being in compliance with the incoming PSD2 SCA regulations.

Many of you will already be using these frameworks as they are already well established by some of the card brands. Their accurate usage and importance is now more relevant than ever as these frameworks will be essential processes to deal with the incoming regulations.

Now is the time to re-visit your payment flows to ensure that you are correctly identifying, flagging and processing these transaction types well ahead of the PD2 SCA enforcement dates in your market.

Incorrectly flagged transactions or those that do not conform to the framework rules will be declined or stepped-up to 3DS when the cardholder is no longer ‘in-session’ – either way the results will be transaction failure and lost sales.

Due to their relative importance to the Travel & Hospitality sector, next month we will be diving deeper into the MIT framework. The use of indirect booking channels brings with it new challenges for this sector where previously unengaged players like 3^rd party booking engines will now need to be integrated more closely to the authentication and authorisation flows. Proof of Authentication needs to be added to each MIT submission and once again, MIT will be a pivotal success factor in your ability to continue providing frictionless flows for your customers.

Meanwhile, please continue to communicate and align closely with your PSP/Gateway/Acquirer who will be able to advise you of the processing possibilities and options available to you within the card brand guidelines for MIT and under the regulation of PSD2 SCA.

[i] The deadline for eCommerce compliance is 31 December 2020 in Europe and 14 September 2021 in the UK.

The 3-D Secure 2 (3DS 2) standard is the global benchmark of card-not-present data authentication. Our upgraded payment solutions use 3DS V2 to protect your eCommerce transactions: verify identities and payment information in a seamless security process that reduces friction and liability, without compromising the customer experience.

Stay ahead of compliance

Implement 3DS V2 to keep your eCommerce solution at the cutting edge of payment security, reducing fraud and enhancing legislative compliance. 

Prepare your business for incoming regulations: 3DS V2 delivers compliance with the Strong Customer Authentication (SCA) requirement, representing the gold standard of card authentication across Europe.

Customer confidence

3DS V2 promises online customers confidence and peace of mind when they shop with you, without intrusive security precautions.

Building on password and text message security measures, 3DS V2 enables customers to authenticate their online payments via mobile shopping apps, using fingerprint or even facial recognition.

Seamless security

Streamline the online card authentication process for businesses and customers. 3DS V2 transfers more payment data elements to banks more quickly and securely, and incorporates specific contextual information, including device ID and transaction history.

No need for website redirects or excessive customer input: cardholder banks take on compliance responsibility, assessing risk levels and either greenlighting payments or challenging customers for further information.  

¹ 2.1+ relates to Mastercard only

The following are the main exemption categories which can be applied by Elavon and/or the issuer:

1. Low Value Exemption

Remote transactions up to €30 (or equivalent in other currencies) and contactless transactions up to €50 (or equivalent in other currencies) do not require SCA up to a maximum of five consecutive transactions or a cumulative limit of €100 (€150 for contactless). If the cardholder initiates more than five consecutive low value payments, or if the total payments value exceed €100 (€150 for contactless), SCA will be required. Please note that currently, only Visa and Mastercard have released their requirements to support exemptions. The monitoring of the consecutive transactions and cumulative limits will be the responsibility of the issuer.

2. Recurring Payment Exemption

Some transaction types are initiated without the cardholder being present or in-session. In these cases, SCA cannot be performed and there are exemptions designed to accommodate these flows. In the case of recurring transactions (same amount) or other customer initiated transactions (variable amount), the initial capture of card details for storing on file must be authenticated using SCA – this results in a unique identifier that is used in subsequent transactions within a series to indicate to issuers that SCA has already been performed. To ensure that these transactions are exempted from

SCA step-up requests, customers and their service providers must ensure that the card scheme MIT

frameworks are followed and that all transactions are appropriately flagged as recurring with reference to the original transaction via the trace/transaction ID value.

3. Transaction Risk Analysis (TRA) Exemption

Issuers and acquirers’ may use TRA on customer’s partners’ behalf to exempt transactions from the need to have SCA performed. This effectively means that Elavon would analyse the transaction to determine the likelihood of it being genuinely performed by the cardholder and exempt it from 3DS. TRA will be available via two channels. Elavon will offer its own TRA service where Elavon will analyse transactions to determine if the transaction can be exempted from cardholder authentication. In addition Elavon will support TRA conducted by approved third parties. Further details on both services will be made available in due course. The issuer however will always have the final say, so for example, where Elavon were to apply the TRA exemption on our customers/partners’ behalf, the issuer retains the right to require SCA (known as step-up). The rules around TRA exemptions are complex and Elavon can only control how the transaction is handled up until the point that it is sent to the issuer. There are three threshold levels of exceptions – €100, €250 and €500. Elavon will be providing more guidance on TRA in the coming months.

4. Trusted Payee Exemption (or whitelisting)

With later levels of 3DS, cardholders will have the option to whitelist’ a business they trust with their card issuer. This means that the cardholder can elect to make a business a‘trusted payee’ and therefore transactions at a ‘whitelisted’ business are to be exempt from future SCA. Whether a cardholder’s elected wishes are upheld is totally the decision of their issuer, as the card issuer may reject the initial request or subsequent exemption requests if it has cause to do so. Furthermore, it is not known at this stage whether issuers will be ready to support whitelisting by 14 September 2019. Elavon are staying very close to developments regarding the Trusted Payee Exemption and will keep our customers/partners’ informed of the latest situation regarding this exemption category as they develop. It should be noted that a business (or their acquirer) cannot elect to be whitelisted themselves, this can only be done between the cardholder and their issuer.

5. Secure Corporate Payments

Payments made through dedicated corporate processes and protocols (e.g. lodge cards, central travel accounts and virtual cards) which are initiated by business entities, not available to cardholders and which already offer high levels of protection from fraud may be exempted from SCA. Elavon is working closely with the card schemes to understand the determination of these transactions and will inform customers/partners once it becomes available.

We expect that card issuers may decide to ask for extra confirmation through the use of voice referrals or an immediate refusal of the transaction. The transaction types currently not supporting the SCA functionality that are most at risk are:

• 3DS1 transactions (where the issuer is only supporting 3DS2)
• Magstripe transactions
• Keyed customer present transactions
• Non-authorised transactions
• Chip fall back
• Deferred authorisations (non-Chip and PIN transactions)
• Unauthenticated eCommerce transactions

References the articles of the Regulatory Technical Standards (RTS) published by the European Bank Authority.

Merchant Initiated Transactions (MIT)

Merchant Initiated Transactions are payments initiated by the customer without the interaction of

the cardholder, for example:

• A single transaction, such as a cancellation fee
• Recurring payments for fixed or variable amounts such as a monthly membership subscription
• A series of transactions for a variable amount or at variable intervals – such as irregular payment instalments for a holiday, or a regular but variable amount such as a utility bill

These transactions must be governed by an agreement between the cardholder and customer that, once agreed, allows the customer to initiate subsequent payments without any direct involvement of the cardholder However, SCA should be applied to the first transaction/action mandating the customer to initiate payment.

Mail Order/Telephone Order (MOTO)

MOTO transactions are not in scope for SCA, as the customer is not in the flow. However, there is a growing trend of fraud and chargebacks on MOTO transactions, and Elavon strongly recommend trying to find ways of taking transactions via eCommerce – perhaps using a Pay by Link type functionality.

MOTO should only be used where the cardholder details have been provided via mail or phone and is not intended to cover customer present interactions via eCommerce or keyed transactions.

Anonymous Transactions

Due to their very nature, payments made through the use of an anonymous payment instrument, such as anonymous prepaid, for example, gift cards, are not subject to the obligation of SCA.

Unattended Transport and Parking Terminals

Any payment for transport fares or parking at unattended terminals (e.g. at an airport or train station) will not require SCA.

One Leg Out Transactions

It may not be possible to apply SCA to a transaction where the Issuer is located outside the EEA1 and is therefore considered out of scope of SCA. SCA should be applied to these transactions on a ‘best effort’ basis.

Since the introduction of PSD2 we have been actively monitoring approval rates to identify any impacts to your business.

We notice that some banks have started to decline or ‘step-up’ contactless payments that require strong customer authentication (SCA).  This happens after a customer has made five contactless payments in a row (or once the payments have totaled €150).  The card will decline and the customer will be asked to insert their card in the machine and enter their PIN. If the transaction is still declined, advise the cardholder to contact their bank and request another payment method in that instance. 

Checkout our ‘Practical Impact Guide for Face to Face’ to assist you through this transition period.