3-D Secure Access-Control Server

👍

Availability

This guide is intended to provide a general outline of new Galileo functionality prior to its release to production. The information in this guide is therefore subject to change as development proceeds and is not a guarantee of future functionality. If you are interested in this feature, contact Galileo for details.

Why this new feature?

Card-not-present (CNP) transactions are especially vulnerable to fraud, because the fraudster does not need to manufacture or steal a physical card to present it in person at a point of sale. To help verify that the legitimate cardholder is making a CNP transaction, many online merchants require an additional layer of authentication.

The 3-D Secure (3DS) protocol provides the framework for authenticating CNP transactions. On 3DS-enabled ecommerce sites, the cardholder must provide proof of identity before completing a purchase, although in some cases, the rules engine determines that the transaction should be "frictionless," and so that step is not necessary.

What this means for your customers

Cardholders who have 3DS-enabled cards can be confident that fraudsters can't easily impersonate them on 3DS-enabled sites. Because the identity of the cardholder is verified before the authorization request is sent, the issuer cannot dispute the transaction. In other words, there is a liability shift from the merchant to the issuer with successful 3DS authentication.

What this means for you

Many countries and jurisdictions require 3DS for online transactions. Galileo's support for 3DS helps you comply with such requirements. Even where 3DS is not required, you can provide an extra layer of security that reduces CNP fraud and helps strengthen your chargeback rights. (3DS must be explicitly supported by a merchant to initiate a 3DS transaction.)

What you provide

During 3DS implementation, you perform these steps:

• Sign an addendum agreement to activate this functionality.
• Provide a list of users from your organization and the roles they will have in the portal.
• Decide the UI merchant framework for the "step up" (additional verification).
• Decide which rules to impose, in conjunction with your bank. You can select from among a large number of transaction characteristics to evaluate, and then you can decide whether to challenge, reject, or pass depending on the criteria. Some characteristics are:
  • Transaction amount
  • Merchant ID, country, or currency
  • MCC
  • Recent cardholder activity
  • Recurring or installment transaction
  • Mobile wallet data
  • Network risk score

What Galileo provides

• To manage your 3DS implementation, Galileo provides a dashboard in the Galileo Client Portal where you can:
  • Review and update security rules
  • Review real-time 3DS events
  • Create custom dashboards
  • Access historic data
  • Analyze trends
  • Export reports
• Galileo returns the results of 3DS authentication to the merchant, and then later evaluates the result along with the
• Galileo provides the result to you in the Auth API and in the RDFs.
  • Auth API
    • aav value (validated, failed, not present)
    • ecommerce object
      • Contains information about authentication attempts and validations, plus the raw_eci if present.
  • RDFs — SLI INDICATOR and PDS0185 (raw AAV/CAVV)
• Galileo leverages its extensive risk-management platform to create a default risk profile to use.

How it works

1. On an ecommerce site, the cardholder attempts to complete a purchase.
2. The ecommerce site sends a 3DS request to Galileo's access-control server (ACS).
3. Galileo retrieves the cardholder information and applies risk rules.
4. Depending on the risk rules, the ACS sends a one-time code via SMS that the cardholder inputs in the interface.
5. The ACS sends the result of the authentication to the merchant.
   • If successful, the merchant sends an authorization request to the issuer that includes a success cryptogram.
   • If not successful, the merchant either does not send the request to the issuer, or the merchant decides to accept the risk and sends the request anyway, with no cryptogram.
6. Galileo evaluates the successful 3DS authentication along with the rest of the authorization request's information.
7. Galileo approves or denies the request based on all of the information in the authentication request. Strong 3DS authentication is more likely to result in an approval.