How does 3D Payer Authentication Work and why has it been introduced

Until recently, Internet based card transactions haveFAC once a merchant is integrated.  The Directory
been classified as 'card-not-present' and 'no signatureServer determines if the card number is in an enrolled
present' so it has been virtually impossible to proveIssuer BIN range, directs requests for cardholder
that the actual cardholder is the person performing theauthentication to the appropriate Issuer (ACS) and then
payment transaction at an Internet merchant site.responds back to the merchant starting the process
The result?  78% of all e-commerce chargebacksof payer authentication directly with the consumer.   
are from 'unauthorised transaction' reason codesFrom the Card Associations Point of View:
commonly referred to as the "I didn't do it"All "attempted" payer authentication requests, whether
chargebacks.validated or not, are stored on the Authentication
This changes with the introduction of 3-D SecureHistory Server (at VISA and MasterCard) providing
services which provides Internet merchants with thedata for acquirers and issuers in the event of a
ability to verify the consumer's true identity through atransaction dispute.  VISA and MasterCard have
secure, electronic, non 'face-to-face' authenticationimplemented payer authentication scenarios based on
process.the responses from the ACS server and the MPI
To press the importance of eliminating card andsoftware that determine liability shift protection for
chargeback fraud on Internet transactions the CardIssuer and Acquirers.
Associations have also instituted chargeback liabilityThe Payer Authentication Process
shift to protect merchants from online fraud and-    Issuers and Acquirers register independently
habitual chargeback offenders.and the service is not interdependent;
How does it work?-    Issuers can be enrolled but not their cardholders;
From an Issuers Point of View:alternatively neither can be enrolled - this drives the
Issuers must license 3-D Secure "Access Controlmerchant chargeback liability shift conditions;
Server" software from a certified vendor.  Issuers-    Likewise, Acquirers can be enrolled but not their
then register BINs directly with Verified By VISA andmerchants leaving the liability for fraud with the
MasterCard SecureCode depending on what cardmerchant if payer authentication is not completed prior
brands they issue.  Issuer BINS are installed on theto the payment authorisation.
ACS server and cardholders are requested to register-    FAC's MPI software communicates with the
their card number with VbV and SecureCode bymerchant's payment page and passes the
selecting a unique password and 'secret phrase.authentication requests to the Directory Server(s) to
From an Acquirers Point of View:validate Issuer enrollment;
Acquirers enroll with VISA and SecureCode to register-    The Directory Server queries to determine if
their acquiring BINs/ICAs.  Acquirers must identify howthe Issuer BIN is enrolled and if yes, communicates with
they will support the MPI to enable 3-D Secure. the Issuer ACS server to validate if cardholder is
Merchants are enrolled by their acquiring bank andregistered;
registered on the MPI (hosted by FAC) and Directory-    If both enrolled, the Directory Server responds
Server.  The Card Associations set up specificvia FAC's MPI and sends the message to the
parameters in BASE I and INET to ensure 3-D Securemerchant to generate the 'pop up' window for the
transactions are flagged correctly for both interchangeconsumer to enter their password information.
price reductions and chargeback handling.  The MID,-    Authentication of the consumer takes place
merchant name, BIN and security certificate are all thatdirectly between the consumer and the ACS server
are enrolled on the Directory Server.  No MCC!through a secure browser connection;
From the Card Associations Point of View:-    The ACS provides the payer authentication
The Directory Server is the 'traffic cop' that managesresponse back to FAC's MPI.  
and monitors BINS and 3-D Secure messagesMerchant proceeds with the payment authorisation
between Issuer, Acquirer and Merchant.  Thedepending on the authentication response codes
Directory server receives authentication requests fromprovided by the MPI.