EMV Specification - Advanced Card Systems Ltd
EMV Specification
EMV Specifications May ‘94- Version 1.0 EMV Part 1Aug ‘94- Version 1.0 EMV Part 2Oct ‘94- Version 1.0 EMV Part 3Jun ‘95- Version 2.0 EMVJun ‘96- Version 3.0 EMV’96May ‘98- Version 3.1.1Dec ‘2000 - EMV2000 (Version 4.0)
EMV Versions 1 & 2 Divided into 3 parts: Part 1 : Electromechanical Characteristics, Logical Interface &Transmission Protocol Part 2: Data Elements & Commands Part 3: Transaction Processing
EMV ‘96 Divided into 3 documentsIC Card Specification Part 1: Electromechanical Characteristics, Logical Interface &Transmission Protocol Part 2: Data Elements & Commands Part 3: Application Selection Part 4: Security Aspects
EMV ‘96 IC Card Terminal Specification Part 1: General Requirements Part 2: Software Architecture Part 3: Cardholder, Attendant and Acquirer Interface IC CardTerminal Specification IC Card Application Specification
EMV 2000 Book 1 : Application Independent ICC to TerminalInterface RequirementBook 2 : Security and Key ManagementBook 3 : Application SpecificationBook 4 : Cardholder, Attendant and Acquirer InterfaceRequirements
Book 1: Application Independent ICC to TerminalInterface Requirement Part 1: Electromechanical characteristics, logicalinterfaces & transmission protocol equivalent to ISO7816 parts 1, 2 and 3Part 2: File Commands and Application Selection
Book 2: Security & Key Management Static & Dynamic AuthenticationPIN Encipherment & VerificationApplication Cryptogram & Issuer AuthenticationSecured MessagingCA PK Management Principles & PoliciesTerminal Security & Key Management Requirements
Book 3: Application Specification Part 1: Data Elements & CommandsPart 2: Debit and Credit Application Specification Files for financial transaction interchangeTransaction flowGenerate AC codingFunctions used in transaction processing
Book 4: Cardholder, Attendant & AcquirerInterface Requirements Part 1: General Requirements Terminal types & capabilitiesFunctional requirementsPhysical characteristicsSecurity requirementsPart 2: Software ArchitecturePart 3: Cardholder, Attendant and Acquirer Interface
World Coverage Canada US Mexico UK Poland CzechFrance SloveniaItaly Portugal Spain Turkey Tunisia Israel Egypt UAE Japan Korea Taiwan HKMalaysia Singapore Brazil Argentina South Africa Lebanon Australia
EMV CardIssuerRequirementsVIS 1.4M/ChipEMV SpecsISO 7816
EMV Specifications: Objectives Universal Acceptance of Chip Debit / Credit CardEnsure that payment functions are performedconsistently & securely at the point of transactionDefine minimum functionalities to support Internationalinteroperability
EMV Concepts Offline risk management decision taken by: Terminal (acquirer) Card (issuer) 3 possible outcomes: Offline approval of transaction Online approval of transaction Denial of transaction Card decision made according to Risk Management Rulesdefined by the issuer
EMV Concepts EMV is a “toolbox.”Each issuer is free to decide on the rules on: Security Risk management Implementation Each acquirer is free to decide on his own riskmanagement parameters.
EMV Concept: Offline ExampleRisk Management RulesOnline if:- Transaction 40- Every 3 offline transactions1. I want to make a 20 transaction – OK?2. Yes. This is the signature.
EMV Concept:Rejected Offline Example3. Is a 30 online transaction OK?ISSUERRisk Management Rules4. OK.Online if:- Transaction 40- Every 3 offline transactions1. I want to make a 30 offline transaction – OK?2. No. Please ask my issuer bank.5. Your bank says OK.6. Here is your signature.
EMV Concept:Online Example3. Is a 100 online transaction OK?ISSUERRisk Management Rules4. OK.Online if:- Transaction 40- Every 3 offline transactions1. I want to make a 100 online transaction – OK?2. Yes. Please ask my issuer bank.5. Your bank says OK.6. Here is your signature.
Offline Transaction Authorization Controls Cardholder Verification 52.95Member Bank Offline Data Authentication TC generationStoreStoreAcquirerVisaNetIssuer123TC 05 Transaction Certificate New Data
Online Transaction Authorization Controls Cardholder Verification Offline Data Authentication0100 ARQC generation (for online request) Authorization Request Cryptogram New Data/Results of offline risk management ARPC validation (for online response) TC generation (for clearing) 52.951234Member Bank Authorization Response Cryptogram New Data0110 Post-Issuance UpdatesStore5AcquirerVisaNetIssuer678TC 05 Transaction Certificate New Data
EMV Specification Coverage- Data Authorization- Data Collection- TransactionStorage- CommunicationProtocol- Risk ManagementTransactionFlow & DataInterfaceInterface &DataNot specified byEMV SpecificationEMV Specification- Cryptography oftransaction- PersonalizationNot specified byEMV Specification
Terminal CoverageEuropay, Mastercard or Visa Requirements- AcquirerParameters- Transaction Log- Parameters- AuthorizationFormat- TransactionSequence- Interface- Communication - Specific FunctionsProtocolEMVEMV Terminal Application
EMV Terminal Transaction licationDataStatic / DynamicDataAuthenticationTerminal icationTerminal ActionAnalysisOn / Offline?OnlineOnline Processing& IssuerAuthenticationOfflineCard ActionAnalysisCompletionScriptProcessing
Transaction Functional Blocks Application SelectionCard AuthenticationCardholder IdentificationAuthorization / Acceptance of TransactionScript Processing
Application SelectionX PrivateApplicationE-PurseApplicationEMV APSelectionEMV D/CApplicationEMVDebit/CreditApplicationEMV APSelectionX PrivateApplication1. What applications do you have ?2. I have the EMV D/C application and the X Private Application3. I only know the EMV D/C application and I select the EMV D/C application.
Application SelectionX PrivateApplicationE-PurseApplicationEMV APSelectionEMV D/CApplicationEMVDebit/CreditApplicationEMV APSelectionE-PurseApplication1. What applications do you have ?2. I have the EMV D/C application and the E-PurseApplication3. I know both but you have priority over the EMV D/C application andtherefore I select the EMV D/C application.
Application SelectionX PrivateApplicationE-PurseApplicationEMV APSelectionEMV D/CApplicationEMVDebit/CreditApplicationEMV APSelectionY PrivateApplication1. What applications do you have ?2. I have the EMV D/C application and the Y Private Application3. I know both applications but the cardholder has chosen EMV D/C,therefore I select EMV D/C.
EMV Card Capabilities Authorization ControlsCardholder Verification MethodsUsage ControlsAuthenticationDynamic Data UpdatesException HandlingMultiple Functions
Authorization Controls Issuer-defined authorization parameters are based on therisk associated with the transaction type or the POSenvironment (eg. online authorization, purchase limit andoffline transaction counters).The chip authorizes the offline transaction.Offline authorization reduces fraud and lower costs.The issuer may establish default online / offline modesdepending on the product or account.The offline default may trigger the online mode based on: Reaching a preset limit to the offline activity (time / amount limit)First time useType of transaction (eg. cashback)Conditions at the POS (eg. PINpad failure)
Usage ControlsThe chip manages card use based on conditions at the point oftransaction using parameters and the processing power of the chip. Geographic Restrict to domestic / international Transaction Restrict usage to local goods & services, ATM, goods & services forinternational transactions, etc. Inactive or expired accounts Force online or decline transaction Ceiling value of cash or cashback transactionMaximum transaction amounts allowedRestricted usage based on merchant type or terminal type
AuthenticationThe chip enables a set of risk management tools, which combat fraudinvolving cryptology & logical comparison between the transactionand card data, to verify the legitimacy of the card and the host. Offline data authentication to prevent fraudulent or altered dataOnline card authentication to detect counterfeited cardIssuer authentication for dynamic data updateTransaction certificate to provide information confirming thatactual steps and processes are performed by the card, the terminaland the merchant during a given transaction.Risk management tools control fraud & provide information thatensure integrity of card transactions.
Dynamic Data UpdateData inside the chip can be updated at the POSwithout reissuing the card, thus providingconvenience to both the cardholder and issuer,and enhancing risk control. Blocking an application or the entire cardUnblocking an application or the entire cardResetting the PIN-try counterChanging the upper consecutive offline limitChanging the lower consecutive offline limit
Exception Handling On-line inoperative The issuer can designate in the card a maximum number of offlinetransactions when the online processing is no longer operative. PIN-try limit exceeded The issuer has the ability to allow more tries under certaincircumstances. Terminal fault Merchants can accept transactions using magnetic stripe. Network fault The processor is allowed to edit the transaction.This feature provides issuers with greater flexibility to customizepayment services on the basis of their risk assessment.
Multiple Function The chip can store information about multiple functions.The chip can communicate with various devices to allowthe selection of different applications at the point oftransaction.The magnetic stripe can provide access to other services.(eg. ATM)It is possible to use the chip for other applications. ( eg.loyalty, electronic purse, membership card, etc.)
EMV Terminal Transaction licationDataStatic / DynamicDataAuthenticationTerminal icationTerminal ActionAnalysisOn / Offline?OnlineOnline Processing& IssuerAuthenticationOfflineCard ActionAnalysisCompletionScriptProcessing
Card Authentication Issues Problem of an international environment (eg. problem ofsharing secrets)Authenticating a Taiwanese EMV card, for instance, in aJapanese terminalNo direct link established between the card issuer andthe terminal applicationPublic key cryptography as a solution to this problem
Static/Dynamic Data Authentication Public key cryptography (RSA) requires a public/privatekey pair to be generated by the payment scheme and theissuer.The owner of the private key is the only one who cansign the message.The public key is known to everyone, and hence able toauthenticate the author of the message.
Static Data Authentication (SDA)IssuerPrivate KeySi(issuer)Payment SchemePublic KeyPi(issuer)Pi certifiedwith SsSi used to create thedigital signature ofthe cardPrivate KeySs(scheme)AcquirerPublic KeyPs(scheme)Distributed to theacquirer, stored inthe terminal
Step 1: Certification of PiIssuerPrivate KeySi(issuer)Payment SchemePublic KeyPi(issuer)Pi certifiedwith SsPrivate KeySs(scheme)AcquirerPublic KeyPs(scheme)Distributed tothe acquirer,stored in theterminalSi used to createthe digitalsignature of thecard The issuer certifies the card.The issuer stores the result (SDA) in the card.
Step 2: PersonalizationIssuerPrivate KeySi(issuer)Payment SchemePublic KeyPi(issuer)Picertifiedwith SsPrivate KeySs(scheme)AcquirerPublic KeyPs(scheme)Distributed tothe acquirer,stored in theterminalSi used to createthe digitalsignature of thecard The payment organization acts as a certification authority.The payment organization’s Ss is used to certify theissuer’s Pi.
Step 3: AuthenticationIssuerPrivate KeySi(issuer)AcquirerPayment SchemePublic KeyPi(issuer)Pi certifiedwith SsPrivate KeySs(scheme)Public KeyPs(scheme)Distributed tothe acquirer,stored in theterminalSi used to createthe digital signatureof the card The terminal verifies the Pi certificate to ensure issuer authenticity.The terminal then verifies the data certificate to ensure cardauthenticity.The proof of card authenticity is static.
Dynamic Data Authentication (DDA)IssuerPrivate KeySic(ICC)Public KeyPic(ICC)Pic certifiedwith Si Payment SchemePrivate KeySi(issuer)Public KeyPi(issuer)Pi certifiedwith SsPrivate KeySs(scheme)AcquirerPublic KeyPs(scheme)Distributed tothe acquirer,stored in theterminalPayment organization certifies the issuerThe issuer certifies the cardThe card dynamically proves its authenticity to the terminal
Card Authentication SDA is the storage of: A certificate for issuerauthentication A digital signature for cardauthenticationDDA is storage of: A certificate for issuerauthentication A certificate for cardauthentication Dynamic generation ofsignature for authenticationCbCbSSDADDASCc
DDA RSA calculation needs a smart card with a cryptographicco-processor.The time it takes to produce a digital signature (1024bits) is approximately 800 ms.
EMV Terminal Transaction licationDataStatic / DynamicDataAuthenticationTerminal icationTerminal ActionAnalysisCard ActionAnalysisOn / Offline?OfflineCompletionOnlineOnline Processing& IssuerAuthenticationScriptProcessing
Cardholder Verification The issuer defines a method and the conditions for identification.The terminal executes according to the agreed methods andconditions.Confirmation of holder identity (photo) & acceptance of thetransaction (signature panel) occurs.Offline PIN verification is done by comparing it with the PIN in thechip.Encrypted online PIN verification is done by the host.The PIN is optional and dependent on issuer market requirements,merchant segments and terminal types.The chip stores and processes issuer instructions on which CVMsare to be used in different situations.This process enhances security and improves issuer control.
Cardholder Verification ExamplePIN online if cash, elsePIN offline if 50, elseSignature PIN Online if the transaction is cashOtherwise, PIN offline if the transaction 50Otherwise, paper signature if the PIN offline is incorrect
Offline Cardholder IdentificationVerify PIN 1233PlainPIN 1234 Card PIN?PIN OK!Verify PIN “# &@”CipheredPIN OK! Ciphering 1234 # &@Deciphering # &@Equals Card PIN?
EMV Terminal Transaction licationDataStatic / DynamicDataAuthenticationTerminal icationTerminal ActionAnalysisCard ActionAnalysisOn / Offline?OfflineCompletionOnlineOnline Processing& IssuerAuthenticationScriptProcessing
Transaction Authorization/Validation Acquirer Risk ManagementTerminal’s DecisionCard’s DecisionIssuer Risk Management
Acquirer Risk Management Terminal risk management is defined by theacquirer.It consists of: Checking floor limit: compare with the transactionamount Random transaction selection: to perform transactiononline Velocity checking: after a number of consecutiveoffline transactions, the transaction should go onlinedepending on consecutive limits, cumulative total,international limits, dual currency amount and limits
Terminal Decision Analyze the result of previous functions. Card authentication result Cardholder identification result Acquirer risk management result Based on the result, a joint acquirer-issuer decision ismade.
Terminal Action ect ?ApprovedTerminal/IssuerOnline approve?Approved OfflineApproved OnlineI reject thetransaction.ApplicationAuthenticationCryptogram (AAC)I want an onlinetransaction.I want an offlinetransaction.AuthorizationRequestCryptogram (ARC)TransactionCertificate (TC)
EMV Terminal Transaction licationDataStatic / DynamicDataAuthenticationTerminal icationTerminal ActionAnalysisOn / Offline?OnlineOnline Processing& IssuerAuthenticationOfflineCard ActionAnalysisCompletionScriptProcessing
Card Action AnalysisI reject thetransaction.I accept anONLINEtransaction.I accept anOFFLINEtransaction. GENERATE AC (CardRisk)GENERATE AC (CardRisk)GENERATE AC (CardRisk)I reject thetransaction.I accept anONLINEtransaction.I accept anOFFLINEtransaction.The card performs its own risk management (not specified byEMV) and makes the final decision.
Issuer Risk Management Performed by the Generate AC CommandIssuer decides its own rulesExamples of possible rules: Counting total consecutive number of offline transactionsCounting total consecutive amount of offline transactionsIncorrect identification of cardholderVerification of previous transactionAnd more Generate ACOnline, Offline, orRejectedEMVNot specifiedby EMV
Script Processing MechanismCard Issuing Bank 1ISSUERDirect link between the card & the issuerRisk Management RulesOnline if:- Transaction 40- Every 3 offline transactionsBank 2 Country 2 TerminalBank 1 Country 1 Card
Script Processing Mechanism Allows issuer to be in contact with their cards duringonline transactionsIndependence of country and acquirerTo do what? Change card parameters Blocking and unblocking of application And more
EMV Card ApplicationEuropay, Mastercard orVisa requirementsEMV-IAC - -Card Risk ManagementAID - Cryptographypersonalisation card
EMV ‘96 ICC Specifications for Payment Systems Part 1: Electromechanical Characteristics, Logical Interface andTransmission Protocols Part 2: Data Elements and Commands Part 3: Application Selection Part 4: Security Aspects
EMV ‘96 ICC Terminal Specification for Payment Systems Part 1: General Requirements Part 2: Software Architecture Part 3: Cardholder, Attendant & Acquirer Interface ICC Application Specification for Payment Systems
Card SpecificationPrerequisite documents to understand Part 1: ISO-7816 1,2,3 Essentially the EMV implementation of ISO-7816 parts 1,2,3Defines Answer To Reset (ATR) charactersRequires a warm reset if ATR is different Possible migration from proprietary/national system to co-existwith EMV without modification of existing systems (eg. TaiwanFISC, Singapore CashCard, etc.) Allows the card to support either the T 0 or T 1 protocolDoes not require Vpp
Card SpecificationPrerequisite document to understand Part 2: ISO-7816-4,6 Defines all data objects (more than 100)Data objects are in TLV formatCan be a primitive data object (eg. TLV or a constructed dataobject like TL(TLV).(TLV))Defines the range of the SFI (file name) to be usedDefines the EMV command setAnd more.
EMV Card Commands 8x 1E8x 188x 160x 828x AE0x 848x CA8x A80x 888x 240x B20x A40x 208xDx, 8xEx,9xxx, ExxxApplication BlockApplication UnblockCard BlockExternal AuthenticationGenerate Application CryptogramGet Challenge (added in EMV2000)Get DataGet Processing OptionsInternal AuthenticationPIN Change / UnblockRead RecordSelectVerifyReserved
Application Selection Terminal cold reset card; If not an EMV card,warm resetSELECT PSE DDF name 1PAY.SYS.DDF01Read FCI using Get ResponseRead DIR EF SFI using READ RECORDRead supported applications using READ RECORD& match supported applicationsSelect the highest priority application supportedby the terminal using the SELECT command onthe ADF
Data Elements for Financial Transaction ICC data objects are stored in: Fixed sized records Variable size records All objects are in TLV format.Primitive data object:Tag (1 or 2 bytes) length (1 byte) valueConstructed data object:TL (TLV)(TLV) . . . (TLV)The value field of a constructed object (TLV)(TLV) . . . (TLV) is called atemplate.
Tag Structure Primitive object tag – 0x,4x,5x,8x,9x,Cx,DxConstructed object tag – 2x,3x,6x,7x,Ax,Bx,Ex,Fx2 bytes tag – odd F (eg. 7Fxx, 9Fxx)Tag is always within the range of 1F to 7F
Examples of Data ObjectsTagLengthValue5F243Application Expiry Date5A10Application Primary Account Number8CVariableCard Risk Management DataObject List 18DVariableCard Risk Management DataObject List 2The above are mandatory data objects.
Examples of Data ObjectsTagLengthValue8F19040-128Issuer Public Key Certificate9340-128Signed Application Data921-34Issuer Public Key (Remainder)9F321-32Issuer Public Key (Exponent)Certification Authority Public Key IndexThe above are static data authentication data objects.
Record Data Object Record in SFI 1 – 10 must be in BER-TLV. SFI 1 to 10 is governed by the EMV specification. SFI 11 to 20 is proprietary data of payment systems. SFI 21 to 30 is proprietary data of the issuer. The tag of a record data object is 70, indicating that it is aconstructed data object.The Application File Locator (AFL) indicates files &records used for transaction processing.
Data Object Existence M Mandatory, must be present to allow terminaltransaction processingR Required, terminal should not terminatetransaction if not receivedC Conditional, necessary under certain conditionsO Optional, necessary under certain conditionsR and C are defined by Visa in the VSDC Requirementsfor Common Personalization document
IC Card Structure MFDFEF: Master File, equivalent to root directory: Dedicated File, equivalent to sub-directory: Elementary File, equivalent to a data file;also called AEF or Application EFDIR File : EF containing a list of applicationssupported by the cardDDF: Directory Definition FileADF: Application Definition File, contains a list ofAEF's for this application
EMV Card OrganizationMF3F00EPURSE ADFADF NAMEDDF1PAY.SYS.DDF01FCIofPSEVSDC ADFA0000000030001CardholderData EF,01 DIREFSFI01ApplicationData EF,02FCI ofDIR EFAuthenticationData EF,03PSE is usually also the MF.Etc.
DIR EF An EF residing inside a DDFSFI must be between 1 to 10, where value is in DDF FCIUsed in the Application Selection processEach entry is a record of the Application Template (tag 61)An Application Template is a constructed objectTagLength4F5-16ADF name (AID)Mandatory501-16Application LabelMandatory9F121-16Application Preferred NameOptional871ValueApplication PriorityPresenceOptional
DIR EF Content70h15h to2Fh61h13h to2Dh4Fh05h to10hAID of Application,5 to16 bytes (M) egA000 0000 0310 1001 Visa CreditA000 0000 0310 1002 Visa Debit50h01h to10hApplication Label, up to 16 bytes (M)9F12h01h to10hApplication Preferred Name, (O)Up to 16 bytes87h01hApplication Priority Indicator,1 byte (O)73h04hCEh70h template proprietary to this application61h application template02hEFID ofapplication’s DF, 2bytes (O)
DDF Implemented as a DF inside the cardMandatory to have the 1PAY.SYS.DDF01 DDF, thePayment System Environment (PSE)Get Response after Select DDF returns the FCItemplateA template is a constructed data objectOne implementation of FCI uses a transparent EFinside the DF to store the Get Response content
PSE DDF FCITagValuePresence6FFCI TemplateMandatory84DF NameMandatoryA5FCI Proprietary TemplateMandatory88SFI of DIR EFMandatory5F2DLanguage PreferenceOptional9F11Issuer Code Table IndexOptional9F3BApplication Reference Currency OptionalBF0CFCI Issuer Discretionary DataOptionalXXXXAdditional object as in book 3Optional
Other DDF FCITag6F84A588BF0CXXXXValuePresenceFCI TemplateMandatoryDF NameMandatoryFCI Proprietary Template MandatoryMandatorySFI of DIR EFFCI Issuer Discretionary DataOptionalAdditional object as in bookOptional3
ADF Implemented as a DF inside the cardCan have many ADFs, with one ADF per application(eg. Credit Card, Electronic Purse, etc.)Each ADF entry can be found in the DIR EF of the1PAY.SYS.DDF01The Application Priority byte indicates: Application selected without holder's confirmationApplication selected with holder's confirmationThe priority of the selection from 1(highest) to 15 or noneCatered for RFU (reserved for future use)
ADF FCITagValuePresence6FFCI TemplateMandatory84DF NameMandatoryA5FCI Proprietary TemplateMandatory87Application Priority IndicatorMandatory9F38Processing Options Data Object ListOptionalBF0CFCI Issuer Discretionary DataOptional
Files for Financial TransactionInterchange EMV specifications only define: The structure The commands to access files Data objects The issuer will map the appropriate data objects to files (SFI1-10) according to their needs, BUT in compliance with therules Linear FREE READ, but may be a conditional UPDATE Each record is limited to 254 bytes, including tag & length Each record is a constructed data object, tag 70 AFL defines the file & record required for applicationprocessing, a response from Get Processing Options.
Cardholder-related Data FileTagValuePresence5F24 Application Expiry Date5AApplication PAN5F25 Application Effective DateMMO5F34 Application PAN Sequence NumberO5F20 Cardholder NameO9F0B Cardholder Name ExtendedO5F28 Issuer Country CodeO5F30 Service CodeO9F1F Track 1 Discretionary DataO57OTrack 2 Equivalent Data9F20 Track 2 Discretionary DataO
Application-related Data uePresenceCard Risk Management Data Object List1Card Risk Management Data Object List2Application Discretionary DataApplication Usage ControlApplication Version NumberLower Consecutive Offline LimitUpper Consecutive Offline LimitCardholder Verifcation Method ListTransaction Certificate DOLIssuer Action Code - DefaultIssuer Action Code - DenialIssuer Action Code - OnlineMMOOOOOOOOOO
Application-related Data FileTagValuePresence9F42Application Currency CodeO9F44Application Currency ComponentO9F4AStatic Data Authentication Tag ListO
Static Data Authentication Data FileTagValuePresence8FCertification Authority Public Key IndexM90Certified Issuer Public KeyM93Signed Application DataM92Issuer Public Key IndexO
VEE – Visa Easy Entry Quick, easy and cost-effective implementation of ICCprogramsInfra-structure supporting future ICC products Multiple applicationsGlobal interoperabilityCo-existence with non-Visa programsAvoidance of confusionAnd more
VEE – Visa Easy Entry Complies with ICC Specification Part 1Complies with ICC Specification Part 3 - Application SelectionSupports a card file with 1 record Track 2 data Track 1 - Cardholder name and track 1 discretionary data Complies with the EMV data coding schemeProcesses transactions using a message format identical tothe current magnetic transactionNo longer in use
VSDC Card Can be a native card (eg. conventional chip operatingsystem powered type of card)Can also be a Global Platform Java Card
Data Preparation before Personalization Issuer public key certificate, remainder, exponentSigned static application dataUniquely Derived Key (derived from PAN and protectedby Key for card authentication)MAC Derived KeyENC Derived KeyOffline PIN
3 Alternatives for VSDC Quick Start data elements in VSDCJump Start data elements in VSDCFull data elements in VSDC
What QuickStart Cannot Do Velocity CheckingStatic Data AuthenticationDynamic Data AuthenticationScript ProcessingOffline PINOffline
What Jump Start Cannot Do Velocity CheckingDynamic Data AuthenticationScript ProcessingOffline PINOffline
Data Elements in VSDC Magnetic Stripe Image (MSI)Authorization Control (AuthC)Static Data Authentication (SDA)Dynamic Data Authentication (DDA)Online Card / Issuer Authentication (CAM / IAuth)Issuer Script for Post Issuance Update(IS)
Possible VSDC TemplatesTemplate1.2.3.4.5.6.7.8.9.10.11.Magnetic Stripe ImageAuthorization ControlEnhanced Cardholder Verification Method (PIN)Offline Static Data Authentication (SDA)Online Card and Issuer Authentication (CAM)SDA, Offline PIN, and Authorization ControlsSDA, Offline PIN and CAMSDA, Offline PIN, CAM, and Authorization ControlsSDA, CAM, and Authorization ControlsOffline Dynamic Data Authentication (DDA)Post Issuance Updates (Issuer Script – IS)
Application Interchange Profile (AIP) Card indicates processing capabilitiesReturns via Get Response after Get Processing Options APDUReturned data – domestic & international AIP, AFL: Tag 80, L var AIP (2 bytes) AFL(n*4bytes) Tag 80, L var AIP (2 bytes) AFL (n*4bytes)AIP Definition:Byte 2 Bit 4 Terminal RiskManagementByte 2 Bit 4 Terminal RiskManagementByte 2 Bit 3 Issuer AuthenticationByte 2 Bit 3 Issuer AuthenticationByte 2 Bit 2,1 RFUByte 2 Bit 2,1 RFUByte 1, Bit 8-1 RFUByte 1, Bit 8-1 RFU
VSDC Template & AIPVSDC TemplateXSDADDACardholderVerificationTerminal RiskManagementIssuer Authetication1. MSI00011000 000000002. Authorization Control00011000 000000003. Enhanced CVM (PIN)00011000 000000004. SDA01011000 000000005. Online Card & Issuer Auth (CAM)00011100 000000006. SDA, Offline PIN & Authorization01011000 000000007. SDA, Offline & CAM01011100 000000008. SDA, Offline, CAM & Auth Control01011100 000000009. SDA , CAM & Auth Control01011100 0000000010. DDA01111000 0000000011. Post Issuance Update (IS)01011100 00000000
Application File Locator - AFL Each AFL is a 4 byte-pointer First byte – SFISecond byte – record # of first record (r1) to be readThird byte – record # of last record (r2) to be readFourth byte – number of consecutive records involved in theSDA starting from r1
Questions?
EMV Specifications May 94 - Version 1.0 EMV Part 1 Aug 94 - Version 1.0 EMV Part 2 Oct 94 - Version 1.0 EMV Part 3 Jun 95 - Version 2.0 EMV Jun 96 - Version 3.0 EMV9
R.O. Writer OpenEdge XCharge Electronic Payment Processing . April 2021 Page 8 of 53 R.O. Writer 1.31 —2.6 . Field Description . EMV Processing/ Account Type . This is the kind of EMV card you want to be able to process. Select . Credit EMV. Device TID for EMV or Canadian Debit . This is the terminal ID used for EMV transactions. You must enter a
EMV Validation (on-behalf-of) Service provides a cryptogram validation and EMV to magnetic stripe service for both EMV contact card and contactless transactions, enabling participants to take advantage . of the cryptogram validation operations via the current authorization messaging infrastructure to the Issuer via Data Element 62. In this .
EMV: A to Z (Terms and Definitions) First Data participates in many industry forums, including the EMV Migration Forum (EMF). The EMF is a cross-industry body focused on supporting an alignment of the EMV impl
Expected Monetary Value (EMV): The EMV is the weighted sum of possible payoffs for each alternative assuming the decision can be repeated many times. To assess the EMV, we must use probability. One of the three generally accepted methods of prob
All of the terminals include an EMV - Smart Card Reader with all the components necessary to process EMV transactions. Fewer charge-backs because EMV proves a card was present Improved dispute resolution Help ensure grea
Cards on KSU 64 If card is a Loop card 64 If card is a T1 card 64 If card is a PRI card 65 If card is an ETSI PRI card 66 If card is a DID card 66 If card is an E&M card 66 If card is a BRI-U2, BRI-U4 or BRI-ST card 66 If
INSTALLATION INSTRUCTIONS: E200465 KIT-EMV-INGENICO ICMP CRADLE-I/M E201088 KIT-EMV-VERIFONE E355 CRADLE-I/M Pg.5 11- Attach bracket (3) assy. to VESA mount with 4 M4 flat head screws* (red arrows). *Use screws in bag E for 10"/15" systems, bag F for systems larger than 15". Attach module USB cable to computer accessory port.
Sarjana Akuntansi Syariah (S.Akun) Pada Program Studi Akuntansi Syariah Menyetujui Pembimbing I Pembimbing II Drs. Sugianto, MA Kamilah, SE, AK, M.Si NIP. 196706072000031003 NIP. 197910232008012014 Mengetahui Ketua Jurusan Akuntansi Syariah Hendra Harmain, SE., M. Pd NIP. 197305101998031003 . LEMBARAN PERSETUJUAN PENGUJI SEMINAR Proposal skripsi berjudul “PERLAKUAN AKUNTANSI TERHADAP .
