Acquiring Card Payments

AcquiringCardPayments

AcquiringCardPayments

IlyaDubinsky

CRCPress Taylor&FrancisGroup

6000BrokenSoundParkwayNW,Suite300 BocaRaton,FL33487-2742

c 2019byTaylor&FrancisGroup,LLC

CRCPressisanimprintofTaylor&FrancisGroup,anInformabusiness

NoclaimtooriginalU.S.Governmentworks

Printedonacid-freepaper

InternationalStandardBookNumber-13:978-0-3673-4284-5(Hardback)

Thisbookcontainsinformationobtainedfromauthenticandhighlyregardedsources.Reasonableefforts havebeenmadetopublishreliabledataandinformation,buttheauthorandpublishercannotassume responsibilityforthevalidityofallmaterialsortheconsequencesoftheiruse.Theauthorsandpublishers haveattemptedtotracethecopyrightholdersofallmaterialreproducedinthispublicationandapologize tocopyrightholdersifpermissiontopublishinthisformhasnotbeenobtained.Ifanycopyrightmaterial hasnotbeenacknowledgedpleasewriteandletusknowsowemayrectifyinanyfuturereprint.

ExceptaspermittedunderU.S.CopyrightLaw,nopartofthisbookmaybereprinted,reproduced,transmitted,orutilizedinanyformbyanyelectronic,mechanical,orothermeans,nowknownorhereafter invented,includingphotocopying,microfilming,andrecording,orinanyinformationstorageorretrieval system,withoutwrittenpermissionfromthepublishers.

Forpermissiontophotocopyorusematerialelectronicallyfromthiswork,pleaseaccess www.copyright.com (http://www.copyright.com/)orcontacttheCopyrightClearanceCenter,Inc.(CCC), 222RosewoodDrive,Danvers,MA01923,978-750-8400.CCCisanot-for-profitorganizationthatprovideslicensesandregistrationforavarietyofusers.Fororganizationsthathavebeengrantedaphotocopy licensebytheCCC,aseparatesystemofpaymenthasbeenarranged.

TrademarkNotice: Productorcorporatenamesmaybetrademarksorregisteredtrademarks,andare usedonlyforidentificationandexplanationwithoutintenttoinfringe.

VisittheTaylor&FrancisWebsiteat http://www.taylorandfrancis.com

andtheCRCPressWebsiteat http://www.crcpress.com

Tomyfather.

5.3.5.4FileControlInformation(FCI)........ 117

5.3.6InitiateProcessing.................... 118 5.3.6.1ApplicationInterchangeProfile....... 118 5.3.6.2ApplicationFileLocator........... 118 5.3.7ReadApplicationData.................. 120 5.3.8OfflineCardAuthentication............... 120 5.3.8.1CommonStepsofOfflineAuthentication.. 121 5.3.8.2KeyChainofTrust.............. 122 5.3.8.3PublicKeyRecovery............. 124 5.3.8.4SignedDataValidation............ 126 5.3.8.5StaticDataAuthentication(SDA)...... 127 5.3.8.6DynamicDataAuthentication(DDA).... 127 5.3.8.7CombinedDataAuthentication(CDA)... 129 5.3.9ProcessingRestrictions................. 130 5.3.9.1ApplicationVersionNumber......... 130 5.3.9.2ApplicationUsageControl.......... 130 5.3.9.3ApplicationEffectiveandExpirationDate.. 130

5.3.10CardholderVerification................. 131 5.3.10.1AmountFields................ 131 5.3.10.2CardholderVerificationRules........ 131 5.3.10.3CVMResults................. 133 5.3.10.4ExampleofaCVMList........... 133 5.3.10.5OfflinePINVerification........... 135 5.3.10.6OnlinePINVerification........... 138

Preface

Atsomepoint,Ihadafewcardschememanualsprintedandbound.Slamming aboutthreethousandpagesonadeskinfrontofanewly-hiredpaymentsystems engineerseemedtoleavealong-lastingimpressionandgetthemintheright mood.Andthosepagesweren’tevennearlyallthedocumentstheywouldhave tobefamiliarwithandskillfullynavigate.

Fewpeoplewhointerviewedforopenpositionsonmyteamhadanypracticalexperienceorweretaughtrelevantknowledgeincollege.Anypre-packaged trainingsonthemarketwereverynarrowlyfocused,overlyexpensiveandinconvenientlyscheduled.

Andtherewasn’tabook,notevenseveralbooks,thatwouldcovertheneeded areaswithoutnosedivingintotoomanydetailswaytooearly.

Exceptthatnowthereis.

Itisnotmeantasareplacementtoanyofthetechnicalstandardsmentioned init,oranalternativetoup-to-datecard-schememanuals.Manydetailswerepurposefullyleftasanexercisetothereaderwho,shouldthejobsorequire,would, hopefully,beabletoreadandcomprehendin-depthinformationinexistingtechnicalstandardsaftermakingsenseofthemwiththehelpofthisbook.

Finally,thebookisdedicatedtocardacquiringonly,andthusonlymentions anyissuer-sidefeaturesorstandardsinsomuchastheyarerequiredforthesake ofcompleteness.

Thus,forexample,protocolssuchasEMV3-DSecurearenotcoveredtothe lastexhaustivedetail.Instead,thisbookprovidesanoverview,justificationand logicbehindeachmessageoftheprotocol,leavingthetaskoflistingallfields andtheirformatstothestandarddocumentitself.

ThelongerchapteronEMVcontacttransactionsismorecomprehensiveout ofnecessity.Incasethereisnoimmediateneedtoknowtheminutiaoftheprotocol,areadercankeeptotheoverview.However,EMVcontactlesscannotbe properlyunderstoodwithoutthefoundationofthefullEMVprotocol.

Ihumblyhopethereaderwillfindthisbookuseful.

PAYMENTCARDS ANDPROTOCOLS I

Chapter1 OverviewofCard PaymentsIndustry

CONTENTS

1.1TheFirstSupper

1.1TheFirstSupper

Throughouttheentirehistoryofcurrency,thepaymentsevolvedalongsideour understandingofmoney.Aspeoplebegantorealizethatmoneyisanidea,the expectationsforsimplicityofpaymentgrewaccordingly.

Betweenabusinessandaconsumer,consumersexpecttheirpaymentmeans toalwaysbeattheirdisposal,beconvenienttouseandsafetocarry.Merchants, ontheotherhand,expecttohavetheirpaymentguaranteed.Bothwouldlike thetransactioncosttobeaslowaspossibleandwouldprefertotodealwith instantaneoustransactions.Bothwouldlikethepaymentmeanstobefraud-safe. Government,anotherunseenbutimportantplayerinthefield,wouldliketotrack purchasestocollecttaxesandpreventfraudandmoneylaundering.

Hardcashdoesnotrankparticularlyhighwithalmostallofthesemetrics.Peoplerunoutofcashinmostatthemostinappropriatemomentorleave theirpursesandwalletsathome.Peoplegetpickpocketedandmuggedforthe cash.Coinsaswellasnoteshavebeenforgedsincetimesimmemorial.Finally,

cash-onlytransactionsaredifficulttotraceandtax,andsogovernmentstendto frownonhigh-volumecashdeals.

Inasense,banknotes,chequesandtraveller’schequesweresupposedtoaddressatleastsomeofthesechallengesinsearchforspeedandconvenienceof payments.

Takecheques,forinstance.Achequecontainssomeindicationofthedrawee orobligor(theorganizationthatproducedit),identificationoftheaccountfrom whichtheamountistobededuced,counterfeitmeasures(which,obviously,grew moresophisticatedwithtime),andasignaturetoverifyauthenticityoftheaccountholder.

Aclientpayingbychequeinastorewouldfillouttheamount,date,payee ofthecheque,signitandgiveitovertothemerchant.Thenthemerchantwould needtotakethechequetothepayeebankandeitherdepositorcashit.Afterthat, thebankwouldtakethechequetoaclearinghousewherethedraweebankwould reimbursethepayeebank.Ifthemerchantandtheclientwerebothcustomers ofthesamebank,thenthebankwouldsimplycheckthebalanceoftheclient accountandsavetheclearingstep.

Technologicaladvancesallowedenhancingchequeswithmachine-readable datathatgreatlysimplifiedtheirprocessingandrouting.Clearinghousesand storecashiersgrewmoresophisticatedaswell,andnowadaysitissufficientto snapapictureofthechequewithyoursmartphoneusingabank-providedapplicationtodepositittoyouraccountalmostinstantly,keepingtheactualchequeas areceipt.

Ofcourse,chequepaymentsusedtobemuchclumsierinthe1950s.However, evendespiteveryrecenttechnologicalimprovements,payingbychequerequires muchmoretimeandeffortthanpayingincash.Thechequestillneedstobe properlyfilledandsigned,chequebooksarequitebulkytocarryaroundandtend torunoutofcheques—sowhilebeingarelativelyconvenientpaymentmethod, itwasstillfarfromaddressingalloftheaforementionedrequirements.

ArevolutionaryeventoccuredinNewYorkin1949.Abusinessmancalled FrankMcNamarawasentertaininghisguestsinarestaurant,andwhenthedinner wasover,reachedouttofootthebillonlytodiscoverthathiswallethadbeenleft inhisothersuit.Hecalledhiswife,shebroughtthewalletoverandthebillwas settled.

ThatcouldhavebeentheendofthestoryifnotforMr.McNamara’sentrepreneurialspiritandthefactthathewasratherannoyedattheinconvenience. Presumably,hewonderedwhyabusinessmanofhisstandingwasnotfreeto spendasmuchmoneyashecouldafford,havingtolimithiscashspendingtothe amountofcashcurrentlyavailableinhispocket.

Mr.McNamaraandhislawyer,FrankSchneider,workedoutascheme:they createdaclubwhosemembers,thediners,wereabletosignfortheirsuppersat restaurantsandsettletheirbillsatalaterdate.

InFebruary1950,afewmonthsaftertheoriginalincident,thetwosatdown inthesamerestaurantandbecamethefirstdinerstosay“chargeit”.Theevent, alsoknownasthe“FirstSupper”,wasthebeginningofthecardpaymentsindustry;thearrangementbecameDinersClub R ,theworld’sfirstcardscheme.

Theinventiontookoffimmediately.Bytheendofthesameyear,Dinershad 20,000cardmembers,whosenumberdoubledin1951,andwithintwoyearsof itsinception,establishedpresenceinCanada,CubaandFrance.Thecardbecame sosuccessfulthatitevenmanagedtoreachbeyondtheIronCurtain—in1961, DinerscardsbegantobeacceptedinCzechoslovakia(nowadaysCzechRepublic andSlovakRepublic)andin1969,intheSovietUnion.

Veryquickly,otherorganizationsfollowedbothintheUnitedStatesand abroad.In1958,AmericanExpress R beganissuingcardsforT&E(traveland entertainment).In1959,BankofAmericamadeitsfirstattempttoissuea“revolvingcredit”cardwhich,inadditiontoservingasachargecard,alsodidnot requirepay-offoftheentirebilleverymonth.Laterthecardlatergrewtobecome theglobalbrandofVisa R .

In1961,JapanCreditBureauandOsakaCreditBureauwerefoundedin Japan.In1965,EurocardInternationalwasestablishedinBrussels.In1967,the sameyearwhenFrancelauncheditsfirstspacecraft,CartesBancaire,association of6Frenchbanks,handlesitsfirstpaymenttransaction.InthesameyearinCalifornia,fourbanksestablishedacompetitortoBankofAmerica’sBankAmericardprogram.ItwascalledMasterCharge:TheInterbankCard,whichinthelate 1970sbecameMasterCard R .

Localmarketsgrewandwentglobal;cardschemeswentoutofbusiness, mergedorwereacquiredbyotherplayers.

InEurope,EurocardInternationalbecameEuropayInternationalandin1992 launchedajointventurewithMasterCard,whichwascalledMaestro.Tenyears later,EuropaywasacquiredbyMasterCard.

InJapan,JapanCreditBureaumergedwithOsakaCreditBureautobecome thedominantJapanesepaymentcardbrand.

IntheUnitedStates,Sears,thenthebiggestnationalretailer,madeaforay intothefinancialmarketandlauncheditsownbrandofpaymentcardsknownas Discover R .LatertheoldestcardschemeDinerswasacquiredbyDiscover.

Emergingmarketslaggedbehind,butbegantocatchuprapidlywithmature European,AsiaPacificandNorthAmericancardschemesinthe21stcentury.In 2002,followingtherapidgrowthofChineseeconomy,ChinaUnionPayTM(later rebrandedasUnionPay)wasfounded.ItbeganasaChinesedomesticschemebut soonoutgrewthemainlandChinatobecomeaglobalplayer,becomingonparor evensurpassingtransactionsprocessedthroughVisaandMastercardnetworksin termsofvolume.

In2012,RuPay,adomesticcardscheme,waslaunchedinIndia.

In2014afterimposingofWesternsanctionsonseveralRussianbanks, NSPK—adomesticcardschemeandaUnionPaywannabewithglobal

ambitions—waskickedoffinRussia.Perhaps,itistheonlydomesticcard schemethatwasdeployedoutofspite.Thecardschemewaslatermarketed undertheMirbrandname.

Attheturnofthe21stcentury,internetfollowedbymobiletechnologyadvanceshadrevolutionizedtheretailindustry.Althoughbiggerandincumbent playerswerenaturallylessagilethannewentreestothemarket,thepayment industryasawholehadquicklyfilledthevoidinthosenewly-appearingareas withsuchprominentplayersasPayPalandAliPayandamultitudeofservice providers,independentsalesorganizations,technologyvendors,alternativepaymentmeans,digitalandmobilewallets,marketplaces,crowdfundingplatforms andevennewelectroniccurrencies(cueBitcoin)comingintobeing.

Ubiquityofpaymentandinterbanknetworks(thelatterconnectingATMs andbanksintoaninteroperablenetworktransparenttoconsumers)hadcaused governmentsaroundtheworldtoincreasinglyseepaymentsasapublicinfrastructure.Governmentsaroundtheworldacttoimproveavailabilityandquality ofservicewhiledrivingdowntransactioncostsbyenforcingstandardization, simplifyinglicensingofnewentreesandbydirectlyregulatingprices.

Majorareasofcardindustrytechnologyandprotocolsaregovernedby ISO/IECstandards,andbignetworkssupportinteroperabilitytoasignificant degree.SecurityforthepaymentcardindustryisgovernedbythePCISecurityStandardsCouncilthroughvariousstandards,andmagneticstripeformats arebasedonISO/IEC.AbodycalledEMVCo(Europay,MasterCard,Visa)has beensetuptostandardizethechipandcontactlesstechnology,andalthoughitis alongtimesinceEuropaywasacquiredbyMasterCardandVisa,MasterCard, AmericanExpress,Discover,JCBandUnionPayareamongtheactualmembers ofthebody,theUStrademarkofEMVisreservedfortheirIntegratedCircuit Card(ICC)technology.

1.2IndustryActors

Theindustrykeepsevolvingwiththetimes,withveteransadjustingtonewtrends andnewandsometimesdisruptiveplayersenteringthegame.Thisecosystem mightbeperplexingascertaintermsaresometimesusedinterchanginglyor meanslightlydifferentthingsdependingonthecontext.Therefore,itisimportanttounderstandwhoisparticipatingintheindustry,whatrolesandfunctions arecriticaltofacilitatepaymentsandhowtheyaredistributedbetweenvarious actors.

Thetwoframingactorsofthemarketarecustomersandbusinesses.Inatypicaltransaction,acustomer(alsoreferredtoas cardholder or cardmember)pays moneyinexchangeforgoodsorservicesprovidedbyabusiness(a merchant) orisrefundedbythebusinessincaseofcancellation,mistakeordispute.Certainly,abusinesscanbeacardholder—itcanholdacorporatecardanduseitfor corporateprocurement.Similarly,amerchantcanactuallybeamunicipalora

governmententity.Finally,amerchantcanbeaphysicalperson,subjecttolocal fiscalregulationandlegalframeworkoftheirjurisdiction.However,regardless ofwhetheritisalegaloraphysicalentity,thereisa payer anda payee andthe goaloftheentireindustryistofacilitatethepayment.

Itcanbedoneeitherbyusingapaymentcardorbyutilizingalternativepaymentmeans—suchasadigitalwallet,avarietyofmobilesolutionsoracryptocurrency.

Paymentcardsandnetworkswhicharelinkedtothem,includingbutnotlimitedtotechnicalinfrastructure,membershipgovernance,riskandcompliance management,brandrules,insuranceandremittanceguaranteesarecalled card schemes.ExamplesofcardschemesincludeVisa,MasterCard,AmericanExpress,Discover,Diners,JCB,UnionPay.Acardschemecanbemanagedby aconsortiumofbanks,byafor-profitcompany(suchasVisaInc.orMasterCard),orbyagovernment-ownedcompany(suchasNSPK).Asinglecompany mightownmultiplecardschemes—forexample,Discoverisalsotheownerof DinersClubcardscheme—orseveralcompaniesmightcontrolacardscheme— asincaseofMaestrowhenitwasjointlymanagedbyEuropayandMasterCard.

Dependingonthecardschemespecifics,additionalinstitutionsmayparticipateinthepaymentcycles.Anentitythatissuescardsforitscustomersiscalled the issuer (sometimes,imprecisely,the issuerbank),whileanentitythatservicesmerchantsandfacilitatesacceptanceofcardsisthe acquirer (or,likewise, the acquirerbank).

Theissuerinstitutionmanagesrelationshipswithcardholders.Itissuescards accordingtocardschemebrandguidelines,trackscardholderbalanceorallowed credit(open-to-payamount)andpaysouttransactionsthatarepresentedtoit byacquirers.Italsomanagescardfraudrisks,providescredittoitsconsumers, collectscardbillpaymentsandmanagesdisputesoffraudulentorinvalidtransactionsonbehalfofthecardholder.

Theacquirerinstitutionisresponsibleforrelationshipswithmerchants.Some acquirersprovidemerchantswithterminalsforacceptanceofcards(acommon practiceinRussia,Israelandsomeothermarkets)whileothersdelegatethisfunctiontoothermarketparticipantsorletthemerchantsbringtheirowndevices(asit isdoneinUnitedStates,JapanorEurope).Theacquirerisresponsibletoprocess transactionsaccordingtocardschemeguidelines,presentingauthorizedtransactionstoissuersforclearing,remittingthefundstomerchantsandmanaging disputesonbehalfofthemerchant.

Theissuerandacquirerrolescanbebornebythesameentity,whichis,in fact,quitecommon.

Bothissuerandacquirermayormaynotalsooperateasaretailoracommercialbank,servicingtherespectiveparty.Forinstance,anissuerthatisaretail bankcanmaintainthecheckingaccountofthecardholder,deductingoutstandingcardpaymentsfromitdirectlyorvalidatingtheopen-to-payamountversus

Figure1.1: Skeletonecosystemoffour-partycardscheme

accountbalance,whileanissuerthatisnotaretailbankrequiresdepositsandissuesbillstothecardholder.Similarly,anacquirerthatisalsoacommercialbank directlycreditsaccountsofitsmerchantsasopposedtoissuingwiretransfers throughacorrespondentbank.

Theskeletonecosystem(see figure1.1)ofmerchant,cardscheme(issuer/acquirer)andcardholderiscomplementedwithprovidersofadditionalservices.

Atypicalmerchantwouldliketoacceptasalargeavarietyofcardbrands aspossibleandcommerciallyfeasible,toprovideitscustomerswiththewidest choiceofpaymentmeanspossible.However,thatwouldrequireveryhightechnicalskillsonbehalfofthemerchant.Inadditiontonecessaryintegrationand certificationprocesses,themerchantissupposedkeeptheirsystemsuptodate andproperlysecure.Thetaskisquitehardforalargeretailchain,whilefora smallshopitisunrealisticandimpossible.

Partiesthatbridgethisgaparecalled PaymentServicesProviders or PSPs. PSPsprovideauniforminterfacetoallsupportedcardschemesandmanagerelationshipsandtechnicalconnectionswithcardschemesandacquirerbanks.Many PSPsprovidevalue-addedservices,suchasadditionalriskmanagementabilities oralternativepaymentmethods.APSPthatalsoonboardsmerchantsonbehalf oftheacquireranddisbursesfundstothemisa PaymentFacilitator (PF)or MerchantAggregator.Thenich´eoccupiedbyPSPsorPFsisshownin figure1.2

Similarlytoanybusinessprocessortechnology,alargemarketincludingsoftwareandhardwarevendors,processingsystemsandbusinessprocesses outsourcinghasdevelopedinthefield.Almostanyfunctionofthepayments industrycanbeperformedbythein-houseteam,orusinganon-premisessystemoftheinstitution,orbyoutsourcingandrelyingonspecializedservices providers.

Anacquirer,issuerorPSPcanoutsourcetheirprocessingtoathird-partyprocessor,focusingonbusinessprocessesinstead.AcquirersandPSPscanemploy servicesofan agent oran ISO (whichinthiscontextstandsforIndependentSales Organization)tofindandonboardnewcustomers.

Apaymentfacilitatorthatalsoprovidesaunifiedmarketplaceforverysmall submerchantsis,inturn,frequentlyreferredtoasa marketplace.

Figure1.2:PSP/PFnicheintheecosystem

Figure1.3:Three-party(or“closed”)schememodel

1.3Three-partyandFour-partySchemes

Therearetwomajortypesofcardschemes, closed and open (or three-party scheme and four-partyscheme)ones.

Inathree-partymodel(see figure1.3,thecardschemeitselfacquirestransactionsandisresponsibleforfinancialsettlementwithmerchants,aswellasissues cardsandbillsthecardholders.

Athree-partymodelallowsthecardschemetoretainthefullestdegreeof controlovercustomerexperience.Theroll-outofchangesaswellasnewproductsandsolutionsisalsosomewhatsimplerduetothelessernumbersofparties involved.Also,thereisnoin-brandcompetition:theschemecontrolstheexperienceandonlycompeteswithotherschemes.Infact,thethree-partymodelisa mixedblessingas,ontheonehand,itallowsforabettergovernanceand,onthe other,opportunitiesforgrowthandinnovationaresometimesoverlooked.

Expansionintonewmarketssuchasnewgeographicalareasrequiresestablishingstronglocalpresence,whichisnotalwayseconomicallyfeasibleorpossibleforathree-partyscheme.Hence,three-partycardschemesfrequentlyrelyon franchisesandpartnershipstomaintainglobalpresence.Suchschemesinclude, forexample,AmericanExpress,DinersCluborDiscover.

Inafour-partymodel(see figure1.4),thecardschemeactsbothasarule setterandafacilitator,butdelegatestheissuingandtheacquiringtootherinstitutions.

Figure1.4:Four-party(or“open”)schememodel

Althoughthefour-partyor“open”cardschememodelprovidescardschemes withlesscontroloverthecustomerexperienceandrequiresadditionaleffortto coordinatetheroll-outofservicesacrossallparticipantinstitutions,itallowsfor amuchfastergrowthofthecustomerbase,sincemakesitpossibletopartner withlocalincumbentsratherthanexpandcard-scheme-ownedpresence.

Examplesoffour-partyschemesareVisa,MasterCardandUnionPay.

Withfranchisesrepresentingthree-partyschemeswhilealsoservingasacquirersandissuersoffour-partyschemes,thelandscapeofcardschemepartners andparticipantsmaybesomewhatconfusing.However,anotherkeydifference betweenthree-partyandfour-partyschemesisthelackorpresenceofthe interchangefees asprimarymeansformutualfeesettlementofacquiringandissuing entities.

1.4PaymentOnlineandattheStore

Paymentcardprocessingcanbedividedintoasmallerobviouspartandamuch largerbehind-the-scenespart.

Acardholderbeginsthepaymentprocessinitiatingthepurchase.Thecard mayormaynotbephysicallypresentatthepointofsale;furthermore,thepoint ofsaleitselfcanbeafullyvirtualshop.Thecardholdermayormaynotusetheir cardnumberassometimesthemerchantcankeepthecardonfile.Thecardholder mayverifytheiridentitybyenteringapersonalidentificationnumber(thePIN), orbyenteringseveralpasswords,fixedand/orgeneratedforthepurposeofthis particulartransaction,ormaytaptheircardatatransitterminalwithoutanyidentityverification.Alloftheseconditionsandmethodsarevalidandaredescribed furtherinmoredetails.However,regardlessofthesespecifics,thereareseveral majorstepswhicharecommonforallpaymenttransactions.

Toillustrateboththecommonalitiesandthedifferencesofpaymentflows, considertheside-by-sidedescriptionoftransactionstepsincard-present,(i.e.,

physicalstoreandphysicalcardenvironment)andcard-not-present(i.e.online) scenarios,asshownin Table1.1.

Fornow,itisassumedthattheterminalortheonlinee-commerceshopis connecteddirectlytoapaymentnetwork.Additionalintermediariesthataretypicallypresentintherealworlddonotaffectthepaymentlogic.

Table1.1:Majorstepsofapayment

Card-presentscenario

AnEMVchiponlinePINtransaction inaretailstore.

Card-not-presentscenario

A3DSecuretransactioninanonline e-commerceshop.

Step1.Cardaccountidentification. Cardholderinsertsthecardintoa chip-readingdevice.Theintegrated chiponthecardinteractswiththe terminalandcommunicatesthe accountnumberornumberslinkedto thecardandotherrelateddetails.

Cardholdertypesinthecardnumber andotheradditionalidentification fieldsintoanonlineformonthe e-commercewebsite.

Step2.Cardverification.

Acryptographicallyprotected exchangeoccursbetweenthe terminalandthecard.Ifeitherthe cardortheterminalhasfailedthe verification,thetransactionis cancelled. Thechipproducesvalueswhichare capturedbytheterminaltobeusedto verifyauthenticityofthecardbythe paymentnetworkortheissuer.

Thecardholderentersanadditional securityvalue(CVV2orCVC2)that iscapturedbythee-commerce softwaretobelaterusedtoverify authenticityofthecardbythe paymentnetworkortheissuer.

Step3.Cardholderverification.

Uponnegotiatingwiththeterminal, thecardrequestsPINtobeentered. ThePINisencryptedbytheterminal andtobelaterusedtoverify cardholderidentitybythepayment networkortheissuer.

Thee-commercesoftwareplug-in redirectsthecardholdertotheir issuer’spage.Theissuerconfirms cardholderidentityusingastatic passwordor,morecommonly,witha one-timepasswordthatistextedto thecardholder’sphone. Oncetheidentityisconfirmed,the issuergeneratescryptographic evidencetobelaterusedtoconfirm thetransactiononceitissubmittedto thenetwork.

Step4.Requestmessage.

Thecardgeneratesacryptographic signaturefordetailsofthe transaction,includingamount, currency,date/timeandotherfields. Theterminalgeneratesapayment message,incorporatingbusiness environmentdetails(terminalID, dateandtime),transactiondetails (amount,currency),encryptedPIN andthechipdata.Thenthepayment messageisforwardedtothepayment network.

Thee-commercesoftwaregeneratesa paymentmessage,incorporating businessenvironmentdetails (terminalID,websitedetails), transactiondetails(amount, currency),issuerauthenticationresult andcardsecuritynumber.Thenthe paymentmessageisforwardedtothe paymentnetwork.

Step5.Response.

Thenetworkrelaystherequesttothe issuerorhandlesitontheissuer’s behalf. Chip-generatedcryptogramandthe PINcodearevalidated,anda decisiontoapproveordeclinethe transactionismade. Theresultissentbacktothe merchantpointofsaleandis displayedontheterminal.

Thenetworkrelaystherequesttothe issuerorhandlesitontheissuer’s behalf. Thecryptographicevidenceandthe cardcheckvaluearevalidatedanda decisiontoapproveordeclinethe transactionismade. Theresultissentbacktothe e-commerceshopandisdisplayedto thecardholder.

2.9.1RetailTransactions ........................................ 36 2.9.2CashWithdrawalsandDeposits ............................ 38 2.9.3PaymentTransactions ..................................... 38 2.10Point-of-SaleTypes,ConditionsandEntryModes ................... 39 2.10.1DataTransferMethods 40 2.10.2DataFormats 40 2.10.2.1TerminalCapabilitiesandConditions 41 2.10.3TerminalCertificationProcess 45 2.11Card-Not-PresentPoint-of-SaleTypes,ConditionsandEntryModes 46

2.1CardShape

Thephysicalcharacteristicsofaplasticpaymentcardaregovernedbyafamily ofstandards,includingISO/IEC7813,7816and14443asthemostprominent ones.Additionalstandardsarereferredtobythesekeystandards,asrequired. TheISO7813standarddefinesthecardsizeandshapeandthemagnetic stripelocation(ifthecardhasit).TheISO7816standarddefinesthephysical characteristicsofasmartcard—acardwithanintegratedcircuitchipembedded intoit.Finally,contactlesscards(cardswithanembeddedantennainadditionto thechip)aregovernedbytheISO14443standard.Considerthecardimagegiven Figure2.1:Annotatedcreditcardimage in figure2.1.Onthefrontsideofthecard,onecanseethefollowingelements: 1.

2. PAN orthecardnumber.PANstandsforthePrimaryAccountNumberand itsformatwillbediscussedshortly.Theembossmentofthecharactersis definedinISO/IEC7811internationalstandard.ThePANisalsoencoded onthemagneticstripeandonthechip,ifpresent.

3. Cardexpirydate.Theformatistypicallytwodigitsofamonthovertwo digitsofayear.Itisalsoencodedbothonthemagstripeandthechip.

4. Cardholdername.Thenameislimitedto26characters.Itishumanreadableonthecarditselfandisalsocontainedonitinmachine-readable format.

5. Cardsequencenumber or CSN.Ifanaccountbyaparticularissueris extendedbeyondtheoriginalexpirydate,theissuercandecideonnot changingtheoriginalPANnumber.Inordertodistinguishbetweenthe oldandnewcardswhichsharethesamePANnumberbuthavedifferent expirydatesandothersecuritycharacteristics,thecardsequencenumber isincreasedbyoneoneachcardrenewal.

6. Integratedchip,sometimesalsoreferredtoastheEMVTMchip.

7. Issuerlogo whichindicatesthebankthatissuedthecard.Informationon theissuerisalsopartofthePAN.

8. Cardproduct.Withinthebrand,therearemultipletypesofcardproducts withvaryingtermsofsettlement,feesandavailablebalances.Theindicationofthecardproductisvisibleonthecard.Besidescardbranding rules,therearealsoregulatoryrequirementsfordisplayofcardtype(for instance,EUregulation2015/751).

Withcertaincardschemes,suchas,forinstance,AmericanExpress,thecard frontsidecontainsanadditionalfunctionalelement(notshownin figure2.1).In thespecificcaseofAmEx,itiscalledthe CID or 4DBC andisavariationof CVVcode(seesection2.5).

BeforetheintroductionofEMVTMtechnology,cardschemesreliedonahologramthatwasembeddedintotheplastic.Asitwasnoteasytobeforged,verifyingavalidhologramwasarequirementforPOSattendantsasanadditionalway toconfirmcardauthenticity.

2.2CardNumber(PAN)

ThePANortheprimaryaccountnumbercanconsistofbetween13to19decimaldigits.Ituniquelyidentifiesthecardaccountandthecardholderwiththe

issuinginstitution.Obviously,multiplicityofinstitutionsandcardschemesrequiredstandardizationandadegreeofcentralizedallocationofnumbersornumberranges.Hence,thePANsaregovernedbyISO/IEC7812standardandhavea well-definedstructure,ascanbeseenin figure2.2.Thecardnumberconsistsof

Figure2.2:PANstructure

thefollowingmajorparts: IIN/BIN, IAN andthecheckdigit(markedasCDin figure2.2.

Thecheckdigitistheretoensurethatthereisnotypoormistakeinthe accountnumber.Itisasimpleparitychecksum,calculatedusingthe Luhnalgorithm (seesection10.1fordetails).

TheBINisanimportantcomponentofthePAN.ItsfirstdigitiscalledMII orMajorIndustryIdentifierwhichidentifies,ataveryhighlevel,theindustryof thecardissuer.SomeoftheMIIsareshownin table2.1.

ItisnotadvisabletorelysolelyontheMIItodeterminecardschemeand brandsincesomeMIIsaresharedbymultiplecardschemes.Also,rangesof

Table2.1:Majorindustryindentifiers

IINnumbersareknowntohavechangehandsduetothestringofmergersand acquisitionsintheindustry.

InordertounderstandtheroleofthecardBINbetter,letusconsiderthematterofanelectronicallycapturedtransaction.Astandardweb-basedUIpromptsa consumerforlittlemorethanthecardnumber,onlysometimesaskingtospecify thecardbrandaswell.

HavingaPANinhand,thesoftwareofthePSPthatservicesanonlinestore istodecidewhetheritisasupportedcardbrand,applyrelevantprocessingrules basedonthatcardbrand(forexample,purchaseamountorcurrencycanbelimitedwithaparticularcard)andthenroutethetransactiontothepropercard schemenetworkconnection.Insomecasesitisalsoimportanttoidentifythe cardtypetoprocessthetransactionsproperly(moreoncardtypesbelow).

Tofacilitateproperroutingandhandlingofvariouscardtypes,cardschemes distributeBINtableinformationtotheirmemberinstitutionsandaffiliates1 .

TheBINtablescontaindefinitionsofsomeorallofthefollowing:

beginningandendofaPANrange(maycoveranentireBINorbeits subrange) cardbrand fulllengthofthePAN(13to19,with16beingthemostcommonone) issuermemberID(mayormaynotbeidenticaltotheBINdependingon cardschemeandinstitutionstructure) cardtypeandproductindicators(moreoncardtypesbelow)

Typically,three-partyschemesdonotprovideelaborateBINtablessincethe technicaleffortthatisrequiredtogenerateanddistributeaccurateandup-to-date dataisnotworththebenefitforit’sconsumers—theschemecontrolsroutingand businessrulesarounddifferentcardproducts.

Withfour-partyschemes,however,thetablesareprovidedtoeligiblemembersroutinelyinformoffullandincrementalupdatesandingreatdetailandas partofroutinefileexchangeoperations.

2.3CardTypesandProducts

Cardsaredividedintoseveralmajorclasses.Firstandforemost,thereisadivisionbetween consumercards and corporatecards,theformerareissuedtoa personwhilethelatterareissuedtocompanies.

Cardsalsodifferdependingon usage orpatternofreconciliationwithcardholders.Thecardusagetypesinclude chargecards (alsoknownas delayeddebit

1FreepublicdatabaseofBINtableentriesisavailableat http://www.binlist.net/

cards), creditcards, debitcards and prepaidcards (sometimesalsocalled storedvaluecards).

Chargecards,theearliesttypeofpaymentcard,allowthecardholdertomake purchasespaidforbytheissuer,andthecardholderbecameindebtedtotheissuer. Thecardholdermustsettletheoutstandingdebtinfullbytheendoftheagreed period(forexample,bytheendofacalendarmonth).Thistypeofcardisalso sometimescalled“delayeddebit”card.

Creditcards arethetypeofcardswhen,similartochargecards,theissuer paysforthepurchaseandthecardholderbecomesindebtedtotheissuer.However,unlikedefaultbehaviorofthechargecard,asfarascreditcardsareconcerned,thecardholdercansettleaportionoftheoutstandingamountwiththe issuer,maintainingrevolvingcreditwithit(andperhapsaccruingahugedebtin process).

Despitetheformaldistinctionbetweenthesetwotypesofcards,thelinesare somewhatblurredinpractice.Itis,ofcourse,possible(andsometimesadvisable) toalwayspaytheoutstandingcreditcarddebtinfull.Ontheotherhand,many chargecardissuersenabletheircardholderstopayforapurchaseininstallments, cappingthemonthlychargeandofferingadditionalcreditproducts.

With debitcards,thecardholdereitherdepositstheamountwiththeissuer orallowsdirectaccesstocardholder’scheckingaccountatabank.Ratherthan payingwithissuer’smoneyandthensettlingwiththeissuer,thecardholderis onlyallowedtomakepurchasesbasedontheirbalanceofthedepositorchecking account.Thefundsaredeductedfromtheaccountimmediatelyratherthanbyend ofafundingcycle.

Prepaid orstored-valuecardsaresimilartodebitcardsinthesenseofthe open-to-buyamountlimitedbythebalanceassociatedwiththecardaccount.The differencesbetweenprepaidanddebitcardsvarybetweenmarkets—inmarkets whereadebitcardistypicallylinkedtoacheckingaccount,aprepaidcardstands outbyhavingadedicatedaccountofitsownmaintainedbytheissuer.Prepaid cardsarealsooftensoldandusedanonymouslyorusedasmeanstoshoponline whileretainingacertaindegreeoffinancialcontrol.

Allpossiblecombinationsofcredit/debitandcorporate/consumercardtypes wereinexistenceatsomepoint.Consumercreditcardsandconsumerdebitcards aswellascorporatecreditanddebitcardsarecertainlyamongthem.

However,simplyclassifyingacardasa“consumercreditcard”isnotenough todescribevariousoptionsandconditionsthatissuerspackageandmarketto theircustomerssinceamuchgreatervarietyofdetailedtermsandconditionsexist.Forexample,issuersoftenmarketcardsforpremiumandVIPsegmentsorofferspecialconditionsforcollegestudents.Suchofferingsvarybetweenmarkets andissuersbutconformtoglobalbrandmarketingguidelines.Thesedefinitions ofindividualissuertermsandconditionssets,conformingtocardschemerules, arecalled cardproducts.

Four-partycardschemesusuallypublishcardproductinformationalongside BINrangesandsubranges.Hence,aBINtablecancontainmultipleentriesthat belongtothesameBINorthesameinstitutionbutwithdifferentproductidentifiers.VisaproductcodestypicallyhaveoneorrarelytwocapitalLatincharacters, whileMasterCardproductcodesconsistofthreecapitalLatinletters.

However,itisimportanttonotethatthesevaluesonlyindicatethecardproductwhichwaschosenforthisparticularaccountwhenitwasfirstcreated.In manycountriesissuerssupportafeaturecalled account-levelmanagement allowingpromotionofanaccounttoadifferentproduct(usuallytoapremium-class productthatcorrespondstothebasisproduct)basedonone’smonthlyorannual spending.Inotherwords,inthecaseofsomeissuersanaccountwithaPAN thatbelongstoarangeofbasiccardscanactuallybeadifferentcardproduct altogether.

2.4TheMagneticStripe

Thebacksideofacreditcardtypicallycontainsthreemajorfunctionalareas: signaturestrip,magneticstripeandacardsecuritycode(CSC).However,perhapsexceptforthesignaturestrip,boththemagneticstripeandtheCSCvalue caninsomecasesbefoundonthefrontsideofthecard.

The signaturestrip isanareathatissupposedtobefilledbyhand.Fortransactionsrequiringthecardholder’ssignature,thecardisnotconsideredvaliduntil itissignedbythem.Inthiscase,anattendantprocessingthepaymentissupposed tocomparethesignatureonthesalesdraftwiththeoneprovidedonthesignature strip,flaggingthetransactionassuspiciousorevencancellingitifcircumstances sorequire.Likemanyothersolutionsthatdependonmethodandprocedure,this onegrewunreliableoncecardpaymentsreallyscaled.

The cardsecuritycode valueisusuallyfoundatthebacksideofthecard, exceptsomecaseswheretwoseparatecodesaredisplayedonthefrontandback sideofthecard.

The magneticstripe (oftenabbreviatedas magstripe)isabandofmagnetic materialcontainingiron-basedparticlescapableofstoringdata.Thedataisread whenthecardisswipedi.e.whenthemagneticstripeisreadbyamagnetichead. Physical-leveldetailsofthedata-storingmethodaredescibedintheISO/IEC 7811standard.

TheoriginalmagneticstripecardreliedonamethodpioneeredbyForrest Parry,anIBMengineerbackin1960s,whoattachedthemagneticstripetoplasticusingaheatingprocess.Asthestorygoes,Parrycamebackhomefromavery frustratingdayattheofficewherehehadmadenumerousattemptstoreliably glueamagneticstripetoaplasticcardandfailedtodothat.Intheend,hesought counselfromhiswife,DorotheaParry,whowasironingclothesatthatmoment, andtriedthethermalmethodtoaffixamagneticstripetoplastic.Herhusband foundthemethodeffectiveandsuccessful.Thatcontributedgreatlytothepro-

liferationofmagneticstripesasthemainmethodforstoringandretrievingcard data.

Althoughcurrentlythestandardisuniversal,paralleldevelopmentofcard processingtechnologyinJapanhasledtocreationofasimilarbutcompeting standardofJIS-U(withISO-compatiblemagstripereferredtoasJIS-T).Besides differencesinthelogicalstructureofdatathatisstoredonaJIS-Umagnetic stripe,itislocatedonthefrontratherthanonthebacksideofapaymentcard. Tocomplywithglobalbrandingstandardsandpreservetechnicalcompatibility withexistingcard-readingdevices,Japaneseissuersproducecardscontainingan invisiblemagneticstripeonthefrontsideandavisibleoneonthebackside. Japanesemagneticstripereaders,inturn,areequippedwithdualmagneticreadingheadsallowingthemtoreadmagneticstripedatabothofISOandJIS-Ucards successfully.

TheISOmagstripehasthreetrackscalled Track1, Track2 and Track3.FormatsofTrack1andTrack2aredescribedinISO/IEC7813,whileTrack3isdetailedinISO/IEC4909.AlphanumericdataonthemagneticstripeisencodedusingANSI/ISOALPHADataFormat,whilenumericdataonthemagneticstripe isencodedusingANSI/ISOBCDDataFormat.

WhileTrack1andTrack2tracksareread-only,theTrack3datacanbe updatedbyaterminal.ItisworthnotingthatTrack3abilitieshavebeenunused bytheissuers,especiallysincetheintroductionofintegratedchipcircuitsand therelatedEMVstandards-basedtechnology.

Tracks1and2containdataregardingthePAN,itsexpirationdate,thecardholderandtheso-called discretionarydata,whichdifferbetweenissuersbut cancontainlargelysametypesofdiscretionalvaluesencodedatvaryingoffsets. Thediscretionarydatatypicallycontainsacryptographicsignatureofsometrack fieldswhichissenttothepaymentnetworkandisusuallyvalidatedbytheissuer. Thissignatureiscalled CVV or CVC andservesasmeanstovalidatecardauthenticitybyrelyingonanopenalgorithmwithasecretkeyknownonlytoissuer.

Incasethecardholdernameisnotapplicable,twoblanksseparatedbya /characterarepopulatedinthefield.

FS—fieldseparator.Alwayscontainstheˆcharacter.

ED—expirydate.Twodigitsoftheyearfollowedbytwodigitsofthemonthof thecardexpirydate.

SC—servicecode.Possiblevaluesoftheservicecodearedescribedbelow(see 2.4.4).

DD—discretionarydata.Itcancontainoneormoreofthefollowingdetails:

PVKI PINverificationkeyindicator.

PVV PINverificationvalue.Computationandvalidationofthevalueis describedbelow(seesection2.8.3).

CVV/CVC cardverificationvalue orcardverificationcode.Computationandvalidationofthevalueisdescribedinsection2.5.

ES—endsentinel.Alwayscontainsthe%character.

LRC longitudinalredundancycheck,thechecksumtoconfirmvalidityof magstriperead(alsoseesection10.2).

2.4.2Track2

MaximumlengthofTrack2is40characters.Exceptforthesentinelsandthe fieldseparatorsandunlikeTrack1,alldatacontainedinTrack2isnumericonly. Thestructureoftrack2isasfollows:

SS—startsentinel.Alwayscontainsthe;character.

PAN—primaryaccountnumber,upto19digitslength.

FS—fieldseparator.Alwayscontainsthe=character.

ED—expirydate.Twodigitsoftheyearfollowedbytwodigitsofthemonthof thecardexpirydate.

SC—servicecode.SamevalueastheSCelementofTrack1(section2.4.1)and describedindetailsinsection2.4.4.

DD—discretionarydata.ThedatafollowsthesamerulesasDDfieldinTrack1 does,containingoneormoresubelementsofPVKI,PVV,CVVandother valuesatissuer’sdiscretion.However,thefieldisnotidenticaltothesame elementinTrack1duetolengthlimitations(Track2isshorter).

ES—endsentinel.Alwayscontainsthe?character

LRC—longitudinalredundancycheckvalue.Seealsosection10.2.

2.4.3Track3

MaximumlengthofTrack3is107characters.Exceptforthesentinelsandthe fieldseparators,alldatainTrack2isnumericonly.Track3wasoriginallydesignedtobeoverwrittenanditcontainsparametersthatcontrolcardholder’s spendingwithinaperiodoftime.However,andespeciallysincetheintroductionofintegratedchipcircuits,thisabilityhadfallenoutofuseandcurrently isnotutilizedbyallmajorcardschemes.Certaincardsevencontainnarrower magnetictapestripandhavenophysicalroomforTrack3.

However,forthesakeofcompleteness,herearethecontentsofTrack3:

SS—startsentinel—containsthe;character.

FC—formatcode,consistsoftwodigits.

PAN—primaryaccountnumber,upto19digits.

FS—fieldseparator,containsthe=character.IncaseanoptionalfieldisomittedafterthefirstoccurrenceofFS,theFScharactershouldappearinits stead.

AdditionaldataofTrack3includesthefollowingfields—refertoISO/IEC4909 fordetails.

Countrycode (optional)—3characters.

Currencycode—3characters.

Currencyexponent—1character.Asarule,amountsarealwaystransmittedasintegerswithapredefinedexponent.Thecurrencyexponentusuallymeansthenumberoftimestheamountshouldbe divided by10toreceivethemajorcurrencyunit(thusanamountof 123eurosandexponentof2means e1.23).However,withTrack 3thelogicisreversed—theexponentdenotesthenumberoftimes theamountshouldbe multiplied by10andwiththeabovevalues, correspondsto e12,300.

Amountauthorized percycle.

Amountremaining thiscycle—thisvalueissupposedtobedynamically updatedwitheachtransaction,alongsidewithcyclebegindate.The ideabehindthesefieldsistotracktheaccountspendingwithoutthe needtoqueryissuer.

Cyclebegin(validitydate)—4characters.

Cyclelength—2characters.

Retrycount—1character.

PINcontrolparameters (optional)—6characters.

Interchangecontrols—1character.

PANservicerestrictions—2characters.

SAN-1servicerestrictions—2characters.

SAN-2servicerestrictions—2characters. SANstandsfor“Subsidiaryaccountnumber”andistiedtothefirstandsecondsubsidiaryaccount numbersbelow.Intheorythemechanismallowslinkinguptotwo additionalsubsidiaryaccountstothePANand,incasewhentheprimaryaccountbalanceisinsufficienttoperformatransaction,todebit thesubsidiaryaccountinsteadorinadditiontotheprimaryone.

Expirationdate (optional)—4characters.

Cardsequencenumber—1character.

Cardsecuritynumber (optional)—9characters

Firstsubsidiaryaccountnumber (optional).

Secondsubsidiaryaccountnumber (optional).

Relaymarker—indicateswhetherdatacanbestrippedfromTrack3in transit

CCD orcryptographiccheckdigits(optional)—6characters.

Discretionarydata —sameasinTrack2.

ES—endsentinel.Containsthe?character.

LRC—longitudinalredundancycheckvalue.Seealso10.2.

AswellasinthecaseofTrack1andTrack2data,theCCDfieldcontainsacryptographicsignature.However,sinceTrack3isdesignedtobeoverwrittenatthe terminal,protectingitcryptographicallyrequiredtheexchangeofcryptographic materialbetweenacquirersandtheissuer.Thatsignificantlylimitedinteroperabilityofcardsthatcanpossiblyutilizethisfeatureand,consequently,restrained itsuptake.

2.4.4ServiceCode

Theservicecodedefinesgeography,specificsoftheauthorizationprocessand therangeofservicesthatshouldbeallowedwiththecardatATMsandpoint-ofsaleterminalsreadingthemagneticstripe.

Eachdigitoftheservicecodehasadifferentmeaning(see figure2.3).

Thefirstdigitspecifiesthepermittedtypeofinterchange—international,nationalorlimitedtobilateralagreementsbetweeninstitutions.Inaddition,thefirst digitspecifieswhethertheICCshouldbeusedifavailable.Somevalidvaluesof thefirstdigitaregivenin table2.2.

Figure2.3:Servicecodestructure

Inthecontextofthepermittedservicecodes,limitationofprocessingtoa bilateralagreementmeansthataterminalisnotexpectedtohandlethisparticularcardunlessexplicitlyprogrammedtodosofollowingaspecialagreement betweentheacquirerandtheissuer.

Theseconddigitspecifiestheauthorizationmodeforthecard.Somepossible valuesfortheseconddigitofthelegacymag-stripeservicecodeareshownin table2.3.

Thisservicecodevaluewassupplantedbychip-basedEMVtechnology, wheretheintegratedchipandtheterminalengageinadialogueandrelyona setofelaboraterulestodeterminetheauthorizationmode.

Thethirddigitlimitstherangeofservicesthatisavailabletothecardandthe cardholder,includingthecardholderverificationmethod(seealsosection2.7). Somepossiblevaluesforthedigitarelistedin table2.4.

Aswiththeauthorizationmode,EMVtechnologyprovidedamoreflexible andelaboratetechniquereplacingtherangeofservicesandcardholderverificationmethoddigitoftheservicecode.

Somecommonvaluesofservicecodesinclude101(norestrictions,internationaltransactionsareallowed),201(preferchip,internationaltransactions areallowed,nofurtherrestrictions),106(preferPINiffeasible,international

Table2.2:Firstdigitoftheservicecode

Table2.3:Seconddigitoftheservicecode

ValueDescription

1Alltypesofauthorizationsallowed

2

7

Onlineauthorizationsonly—transactionsmustbeauthorizedby contactingtheissuer

Onlineauthorizationsexceptwhengovernedbyabilateral agreement

Table2.4:Thirddigitoftheservicecode

ValueDescription

0Norestrictions,PINvalidationismandatory

1Norestrictionswhatsoever

2Goodsandservicesonly,cashnotallowed

3ATMonly,PINrequired

4Cashonly

5Goodsandservicesonly,cashnotallowed,PINrequired

6Norestrictions,prefertousePIN

7Goodsandservicesonly,prefertousePIN

transactionsareallowed)and206(preferPINiffeasible,internationaltransactionsareallowed,preferintegratedchipiffeasible).Fordebitcards,valueof226 (preferchip,preferPIN,alwaysauthorizeonline)isalsoquitecommon.Achipcontainingcard’sfirstdigitoftheservicecodewouldtypicallybe2,directingthe terminaltopreferchipifasupportingreaderisavailable.

2.5CardVerificationValues

Letusconsiderafraudscenariowhenacriminalstealsthecardnumberandaccountexpirydateandproducesacounterfeitcard.Thiscanbedone,forinstance, byinterceptingamailorderorbycopyingthedetailsfromacardsalesdraft.The detailscouldlaterbeusedtoshopbymailortelephoneorderortocreateanew magneticstripecardanduseitinphysicalstores.

Alternatively,afraudstercouldreplicateanactualcardandmodifyitsservicecode,which,intheworldofmagneticstripes(i.e.,withoutintegratedchip circuits)couldcausedevicesnottovalidatethetransactionsonlineornotrequire aPINcode.Topreventthistypeofattack,acryptographicmethodforcardintegrityprotectionhasbeendevised.Aspecialcheckvalue,knownastheCard SecurityCode(CSC),CardIdentificationNumber(CID),CardValidationCode (CVC),CardVerificationValue(CVV)orCardValidationNumber(CVN),is

calculatedbytheissuerandisstoredonthemagneticstripe,printedonthecard, storedontheintegratedcircuitchiporcalculateddynamicallypereachtransaction.Forthesakeofsimplicity,wearetorefertoitasCVVfromnowon.

TherearefourtypesofCVVvalues:

CVV (orCVV1)—storedonmagneticstripeandusedtovalidateitsauthenticity.

CVV2—printedonthecardandusedtovalidatecardauthenticityincard-notpresenttransactions(mailorder,telephoneorder,electroniccommerce).

iCVV—storedontheICC.AlthoughEMVtechnologyprovidesamuchmore reliablewaytovalidatecardauthenticity,themethodwasdevisedtosimplifytransitionandallowforinteroperabilitywithsystemsthatdonotyet supporttransmissionandhandlingofchipdata.

dCVV—thedynamicCVViscalculatedbytheintegratedchipbasedoncard transactioncounterandanexternalunpredictablenumber.Thisvalueis usedtosecurecontactlessmagstripetransactions.

2.5.1CVVCalculationAlgorithm

TheCVVisaone-wayhashfunctionofcertaindataelements.Exceptforthe dynamicCVV,alloftheaforementionedtypesofcardverificationvaluesare calculatedusingsimilarprinciples,bututilizingadifferentsetoforiginaldata.

ThedynamicCVVreliesonuniquederivedkeysandhard-to-predictdata thatchangeswitheverytransaction.AllotherCVVtypesrelyonaCVK(Card VerificationKey)thatiskeptasaguardedsecretbytheissuer. Thealgorithmhasthreesteps:

ThedatavectortypicallycontainsPAN,expirydateandtheservicecode. Topackthedata,thelast16digitsofthePANareused.IfthePANlengthis lessthan16digits,itispaddedwithzeroesfromtheleft.Then,theexpirydateis concatenatedwiththePAN,theservicecodeandtheoverallresultispaddedwith zeroestothetotallengthof128bits,whilealloftheabovevaluesarenumeric onlyandarepackedintonibblesashexadecimaldigits.

Thus,forexample,thePANnumberof90123456789012(14digitslong), expirydateofOctober2018andservicecodeof101willbetranslatedintotwo 64-bitblocks,asshownin figure2.4

Figure2.4:CVVcalculationblock1and2

TheCVKorCardVerificationKey,beinga3-DESkey,consistsoftwo64-bit parts,KA andKB.ThefollowingstepsarethenperformedwithBlock1(further denotedasB1)andBlock2(B2):

1.B1 isencryptedusingKA toobtaintheintermediaryvalueR1.

2.Theresultofstep1,R1,isXOR-edwithB2 toobtainanintermediary valueR2.

3.ThevalueofR2 isthenencryptedusing3-DESencryption(seesection 12.2)withKA andKB,meaningthatthevalueofR2 issequentially:

(a)encryptedwithKA

(b)decryptedwithKB (c)encryptedwithKA

Forthesakeoftheexample,letKA be 0123456789ABCDEF andKB FEDCBA9876543210.Then,R1 wouldbe CECFBC9F0529CAB5.AfterXOR-ing itwithB2,theintermediaryvalueR2 is DED7AC8F0529CAB5.Finally,afterencryptingitwith3-DESencryption,theoutcomeis 37BAE5346B2D2C52.

Forstep1ofthealgorithm,someschemesmayrelyon3-DESencryptionof thedatainsteadofasingle-DESencryption.Thisalignsalgorithmtoastandard CBCcomputationofHMACwithinitializationvectorsetto0(seealsosection 12.4).

Theresultisa64-bitvectorthatcontainsabinaryvaluewhichatthisstage shouldbedecimalized.Thealgorithmfordecimalizationisasfollows:

1.Alldecimaldigits,lefttoright,areextractedfromthevalue.

2.Allremaininghexadecimaldigitsaretakenmodulo10andappendedto thevaluefromstep1.

Figure2.5:CVVdecimalization

3.Necessarynumberofdecimalplaces(3or4)isthentakenfromtheresult toobtainthenecessaryCVV.

Anexampleofdecimalizationcanbefoundin figure2.5.Theresultofthe calculationwouldbe3,753.

Byrepeatingthecalculation,theissuerisabletoverifytheauthenticityof thesubmittedcarddata,dependingonthetransactionprocessingscenarioand transactionconditions.Obviously,compromiseoftheCVKrenderstheentire mechanismunreliable.DuetothesensitivityofCardVerificationKeys,theyare typicallystoredinHSMs(hardwaresecuritymodules),towhichthefunctionof CVVvalidationisalsodelegated.

Ascardschemesprovideservicesforstand-inprocessing,handlingincoming authorizationrequestsonbehalfoftheissuerincertaincases,theCVKandPVK values,alongsidetheirspecificlocationsinthediscretionarydatapartofmagnetictracks,areeithersharedwithcardschemesorprovidedbycardschemes. Intheformercase,thekeysaregeneratedbytheissuer,andinthelattertheyare generatedandsecurelydeliveredbythecardscheme.

2.5.2CVV1

TheCVV1valueisstoredaspartofdiscretionarydataonTrack1orTrack2of themagneticstripe.ThepurposeofCVV1isensuringthecardauthenticityand preventingfraudcaseswhenfraudstersmightobtainthePANandexpirydate andusethemtocreateaduplicatemagneticstripecard.

Inaddition,thepresenceoftheCVV1valuemakesitimpossibletobypass limitationsimposedbytheissuerintheservicecode.Considerthescenariowhen acertaincardisprohibitedforinternationaluseandalwaysrequiresonlinevalidationbytheissuerandaPINcheck,carryingtheservicecodevalueof520.

Insomecases,settingthevalueto101mightallowusingthecardaftercrossing acountryborderandataterminalthatdoesnotauthorizethetransactiononline immediately.However,thevalueisalsosignedbyCVV1,renderingthisbypass impossibleaswell.

ThelengthandlocationoftheCVVvalueaspartofdiscretionarydatathat isstoredonTrack1and2isusuallyprescribedbythecardscheme.Duetohigh sensitivityofthefield,neithertheCVV1vlauenortheentirevalueofTrack1 and2shouldbestoredbyanyentityinvolvedinthetransactionaccordingtoPCI DSSstandards(seesection8.1(PCIDSS)).

2.5.3CVV2

TheCVV2valueisusedtovalidatecardauthenticityincard-not-presenttransactions,suchastelephonyordersorelectroniccommerce.Thecardholderisrequiredtoenterthevalueorspellittothephonerepresentativetoprovethatthe actualcardisinhispossession.Thevalueistypicallyprintedonthebackside ofthecardandcontainsthreedigits.However,onAmericanExpresscardsan additionalCVV2value(4DBC)has4digitsandislocatedonthefrontsideof thecard.

ThealgorithmusedtocalculatethevalueisidenticaltothatofCVV1.However,servicecodelimitationsareuselessanddonotapplytocard-not-present transactions,and,therefore,avalueofthreezeroes(000)isusedinitsstead.

TheissuercanchoosetouseaseparatesetofCVKsforCVV1andCVV2, orrelyonthesamesetofkeysforbothvalues.

2.5.4iCVV

Afull-gradeEMVimplementation,whentheterminal,theacquirersystem,the networkandtheissuerallsupportnecessaryEMVfieldsreliesonmethodsfar moresophisticatedandstrongerthanCVVforcardauthentication.However, sincetheintroductionoftheEMVtechnologytovariousmarketsrequiresatransitionalperiod,certainprovisionshavebeenmadetosupportpart-gradeEMV, i.e.,inparticularscenarioswhentheterminalandtheintegratedchiponthecard engageinanEMVdialogue,buttheterminalthenreliesonitslegacyprotocolto transmitcarddatatotheacquirerhost.

Inthiscase,thepaymentmessagecontainsmagneticstripedataonly.The dataisstoredontheintegratedchipandreturnedtotheterminalbythechip. ThatraisesaconcernthattheTrack2datacanbeskimmedfromthechipand usedtocreateamagstripe-onlycardwithidenticalmagnetictrackcontents.

Tocountertheaforementionedtypeoffraud,thechipstoresastaticCVV valuethatdiffersfromCVV1andCVV2.ThevalueiscallediCVVandiscalculatedusingexactlythesamealgorithmonlywithservicecodesetto999.Having aseparateverificationvalueforchipcardsinapart-gradeenvironmentprovides

theissuerwithanadditionaldistinctionbetweencaseswhenthecardisreadby thechipreader(and,therefore,thediscretionarydatacontainsitsiCVV)and whenthecardisreadbythemagstripereader(withCVV1valueembeddedin thediscretionarydata).

TheissuercanopttocalculatetheiCVVproperlyaccordingtotheverificationalgorithm,orsimplyplaceaninvalidCVVvaluethat,ifusedaspartofa skimmedmagneticstripecard,causestheexistingvalidationmechanismtofail.

2.5.5DynamicCVV

IntheContactlessEMVenvironment,manycardschemessupportaso-called “Magstripe”modeforpart-gradeenvironmentstoripsomebenefitsoftheadvancedtechnologywhilerelyingonlegacyinfrastructure.Insomeimplementations(see chapter6 fordetails)thePOSsubroutine(aKernel)iscapableof operatinginaspecialdedicatedmodewheneitherusingadedicatedsetofcommands(seesection5.3.2.2fordescriptionofcommands)orbyrelyingonadditionaldataelements,theKernelgeneratesTrack1andTrack2databasedonthe valuesreturnedbythecard.

TheKerneltypicallyprovidesarandomvalue(“unpredictablenumber”)to thecard,whichgeneratesaone-timeverificationvaluebasedonit.Thenthe numberandtheverificationvalueareembeddedintoTrack1and/orTrack2 fieldsintheirDiscretionaryDatapart.Thisverificationvalueiscalled dynamic CVV or dCVV,asitissimilartoothercardverificationvaluetypesinitsformat andembedding.ThevalueisalsosometimesreferredtoasCVV3.

2.6OverviewofCard-PresentTechnology

Typically,severalmajortechnologiesareusedincard-present/cardholder-present

Magneticstripe—there,ofcourse,isthemagneticstripethatisbeinggradually phasedoutgloballyduetoitsnumerouslimitationsandvulnerabilities.

EMVchip—EMVtechnologyhavingcontactreadersandintegratedchipcircuitsembeddedintocads,wherethecardistobeinsertedintoacompatiblereaderandthechiponthecardengagesinadialoguewiththeterminal.

EMVcontactless—isalsoanICC-basedtechnology,havinganantennaisembeddedinthecardinadditiontothechip.Whenplacednearacompatible reader,thechiponthecardispoweredbyelectromagneticinductionof thereader’smagneticfield.Thenthechipengagesinadialoguewiththe reader.

EMVtokenization

—atechnologythatcombinessecuritybenefitsoftokenized cardswiththoseofanEMVchip,allowingin-storepaymentusingatoken.InsteadoftheactualPAN,thetokenidentificationistransmittedto theterminalinstead.Thattechnologyisbehindsuchpaymentmethodsas ApplePay R ,AndroidPay R ,SamsungPay R ,etc.

Implementationsofbothchipandcontactlesstechnologiesarestillunderway, andthemagneticstripecardsandreadershavenotbeencompletelyphasedout. Asthereisstillaconsiderablenumberofmagstripe-onlycardsinuseaswell aslocationswheresuchcardsarestillissued,terminalsareexpectedtocontinue supportingmagneticstripesforyearstocome.Besidescompatibilitywithmagneticcards,thatprovidesanadditionalbenefitofbeingabletofallbacktoa magneticstripetransactionincasethereisaproblemwiththecardreaderorthe chipitself.

End-to-endimplementationofEMVtechnologyisalsosometimescalled fullgrade EMV.Inafull-gradeEMVimplementationthecardandtheterminalrely onEMVprotocolsfortheexchangeofpaymentdata.Thepaymentmessage,containingalltheadditionalvaluesgeneratedbycardandterminal(thesearecarried inISOfield55),issentthroughtotheacquirerhosttothepaymentnetworkand totheissuer.

However,hostsystems’andnetworks’upgradestosupporttheextradata takestimeandrequiresconsiderableeffort.Hence,theEMVstandardsallow a part-grade EMVimplementation,meantasatransitionalstateofapayment solutionthatutilizessomebutnotalloftheEMVfeatures.

IncaseofbothcontactandcontactlessEMV,whilethedialoguebetween theterminalandthecardisperformedaccordingtoEMVprotocol,themessage thatissentfurtherdownthelineconformstoamagstripetransactionformat.In otherwords,insteadofafull-gradecryptographicsignatureofthetransaction data,alimitedandsimplermethod,utilizingthediscretionarydatasubfieldsof Track1andTrack2magneticstripevalues,isused.Inparticular,thatmeansthat insteadofanARQC,theissuerreliesoniCVVordynamicCVVtoconfirmthe cardauthenticity.Moredetailsonthoseabilitiesandconditionscanbefoundin section2.10.Seealsosections2.5.4,2.5.5.

Thedescriptionoffull-gradeEMV,chiptechnologyandprotocolsisgivenin detailin chapter5.

2.7CardholderVerificationMethods

ThecardistypicallyidentifiedbyitsPAN(andsequencenumber,ifmultiple cardswereissuedfortheaccount)andauthenticatedbyoneofthecryptographic methodsmentionedelsewhereinthisbook.

Oncetheauthenticityofthecardisconfirmedbytheterminalanddatafor furtherauthenticationbytheissuerisgathered,cardholderverificationusually takesplace.

Inacard-not-presentenvironmentwhichincreasinglyconvergeswithcardpresentonmobiledevices,additionalmeansofauthenticationsuchas3DSecure(VerifiedbyVisa/SecureCodeorothers),itssuccessorEMV3DS2.0ora digitalwallet(VisaCheckout R ,MasterPass R ,AmExExpressCheckOut R )are frequentlyapplied.Inthesecases,thecardholder’sidentityisverifiedbyoneor moreofthefollowingmeans:

Staticpassword whichisdefinedbythecardholderonadigitalwalletorthe issuerbankwebsiteaccordingtoissuer’sorwalletprovider’spasswordsecuritypolicy.Themethodisusedindigitalwalletapplicationsandsometimeswith3DSecure-basedapplications(seesection4.3).

One-timepassword whichisgeneratedbytheissuerorwalletproviderandis communicatedtothecardholderviaanindependentverifiedchannel.Most frequently,theone-timepasswordissenttothecardholderasanSMS message.Themethodisusedforweb-basedcommerce,sincetheaccessto amobilephoneisubiquitous.Asignificantlymoresecuremethodforonetimepasswordgenerationinvolvesamobileapptiedtoaspecificmobile devicethat,uponenteringapasscode,generatesaone-timepasswordthat expireswithinshorttimeframe,typicallyoneminute.Thismethodisrarely usedformassend-userauthentication.

Mobileauthentication

isexclusivelyusedwithmobilecommercetoauthenticatethecardholder,confirmingthatmobiledeviceorapplicationuser isindeedtheowneroftheaccount.Multiplemethodscanbeusedforthat typeofauthentication,withpasscodes,passwords,swipepatterns,andfingerprintsbeingusedmostfrequently.Thesemethodsaregrowingmore sophisticatedwithfurtherdevelopmentofmobiledevicetechnologyand someexperimentalauthenticationapproachesincludeenhancedswipepatternrecognitionthattakesintoaccountthespeedandangleofthepattern swipe,gesturerecognitionmethodrelyingonaccelerometers,aswellas voiceandfacialbiometricrecognition.Itisworthnotingthatitisimportanttodistinguishbetweenanumericpasscodeusedtounlockmobile devicesorauthenticatemobileapplications,andthecard-relatedPersonal IdentificationNumberorPIN.Theformeristypicallysharedandused bythesmartphoneuser,themobileapplicationandthedevicewhilethe latterhasstrictentrydevicerequirements,securityguidelinesandaudit processesensuringitssecurity.Thispasscodeissometimesreferredtoas mPIN,todistinguishitfromPINandPIN-basedcardholderverification methods(seeOfflinePINandOnlinePINbelow).

Inthecard-presentenvironment,thereisaclosedwell-definedlistofCardholderVerificationMethodsthatiscodifiedaspartoftheEMVstandard.Some ofthesemethodsareperformedbyaterminalattendant,somecanbeexecutedby thechiponcardandtheothersrequiretheissuer’sinvolvement.Thesemethods areasfollows:

FailedCVM—isatechnicalCVMmethodthatismentionedhereforthesakeof completeness.Itisprimarilyusedinexceptionalscenariosandindicates thatthecardhasdecidedtopurposelyfailallCVMchecks.Forexample, anissuermaydecidetoput“failedCVM”asthelastcardholderverificationruleintheCVMlistonthecard,tomakesurethatifnootherruleis applied,thecardholderverificationistobeconsideredfailed.

NoCVM isthe“zerohypothesis”ofcardholderverificationmethods.During theinteractionbetweenaterminalandachipcard,orduetolimitations predefinedontheterminal,authorizationmaybeattemptedorperformed withnoadditionalcardholderverification.Usuallythatmethodisapplied inunattendedterminalssuchasvendingmachines,offlineterminalsand onpublictransit,whereaPINcodeorotherverificationmethodleadsto unreasonablecongestionandpassengertrafficbuild-up.

Signature—isthelegacymethodofcardholderverificationduringwhichtheterminal,ifequippedwithaprinter,printsasalesdraft.Thentheattendant asksthecustomertosigntheslipand,atleastaccordingtoregulations,is supposedtocomparethesignatureontheslipwiththeoneonthesignature stripeonthecard.Themethodhasobviousdeficienciesasbesidesrelative easeofforgingthesignaturethatisalreadypresentonthecard,shopattendantsoftenskipthesignaturecomparisonstep2.Obviously,themethod doesnotdependonEMVtechnologyandcanbeusedwithamagnetic stripecardaswell.

OfflinePIN—ispartoftheEMVspecification;thismethodisfurthersubdivided into plaintextofflinePIN and encipheredofflinePIN.Inbothcases,the integratedchipcircuitonthecardistheentitythatconfirmsPINvalidity andthusverifiesthecardholderidentity.AsforthecleartextofflinePIN, thevalueofthePINenteredistransmittedtothecardunencryptedand inthecaseoftheencipheredoneexactlyasthenameimplies.Terminals thatareequippedwithaPINpad(certifiedandEMV-compliantPINentry device)aretypicallyabletosupportbothmethods,andthechoicebetween plaintextandencipheredofflinePINvalidationislefttotheissuerand limitedbytheintegratedchipcapacity(withencipheredPIN,obviously, placinghighercomputationaldemandsonthechip).Theprocessitselfis describedinmoredetailsinsection5.3.10.5.TheISO/IEC9564standard governsencodingofPINdatathatisexchangedbetweentheintegrated chipandthePINpad(seealsodescriptionofformat2in Chapter13).

2AsofApril2018,shopsthatacceptEMVcardsarenolongerrequiredtokeepcardholdersignatures.

OnlinePIN—ispackagedintoanencryptedPINblock(referredtoasEPB)and issenttotheissuerforvalidationalongsideothertransactiondetails.There areseveralformatsoftheEPBasdefinedbyISO/IEC9564(seedescriptionofformats0,1,3and4in chapter13).ThePINblockisencrypted bytheterminalusing3-DES.ThentheencryptedPINblockundergoes several“PINtranslations”byaterminalmanagementsystem,acquiring hostandthepaymentnetworks,duringwhichtheEPBisdecryptedand re-encryptedagainusingthesymmetricsecretkeysharedbetweensubsequententitiesintheconnectionchain.Thatverificationmethodalsodoes notdependonEMVtechnologyandcanalsobeusedwithmagneticstripe cards.

Themethodsandtheformatofcardholderverificationrulesaredescribedin moredetailsinsection5.3.10.2.

2.7.1StrongCustomerAuthentication

Cardholderverificationservesasasteptoensurethatthepaymentisperformed byitsrightfulowner.Whilethesemethodswereinitiallydeployed,withvarying degreeofmarketpenetration,asawayformarketplayerstobettersecuretheir transactionsandcombatfraud,sinceSeptember2019theso-called“StrongCustomerAuthentication”hasbeenmandatedbylawintheEuropeanUnion,albeit withsomespecificexemptions.

TheStrongCustomerAuthentication,orSCA,requiresacombinationofat leasttwodynamicallylinkedfactorsof“somethingyouare”,“somethingyou have”and“somethingyouknow”typestoauthenticatethepaymentaccount owner(inthecardworld,thecardholder)priortoperformingapaymenttransaction.

Whileinthecard-presentenvironmentonefactorofauthenticationisthe carditself(somethingthecardholderhas),andvariousPIN-basedmethodsadequatelymeettherequirementsofthelaw,inthecard-not-presentenvironment onlymandatory3DSecure-basedcardholderauthenticationhasprovidedthe necessarylevelofcompliancewiththeSCArule,andthatonlyiftheactual authenticationiscorrectlyimplementedbythecardissuer.

2.8PINHandling

2.8.1PINVerification

TherearetwopossiblePINverificationmethodsdependingonthedecisionof theissuer.ItispossibletoeitherstorethePINinthedatabaseinencryptedform, delegatingitsvalidationtoanHSM,ortorelyonPVV—thePINcodeverificationvalue—thatishandledandutilizedinamannersimilartothatofCVV(see

section2.5),whenonlytheverificationkeyiskeptsecretandthevalidationvalue arrivesalongsidetheencipheredPINvalue.

2.8.2StoringEncryptedPIN

IftheissuerdecidesonstoringthePINvalueitself,thePINvaluesareencrypted inasecurewayinsideanHSMandthentheresultoftheencryptionisthenstored inadatabaseontheissuerhost,alongsideeithertheindexoftheencryptingkey ortheKEK-encryptedkeyitself(seealsosection8.3.2).Theissuerstoresthe ethalonPINencryptedunderPEK(PINencryptionkey),anindexofthePEK orthevalueofthePEKitselfunderKEK(PEKKEK).Theissuerreceivesan encryptedPINblockaspartofthepaymentmessageandhandsitovertothe HSMwiththeethalonPINandthenecessarykeyinformationtovalidatethe PIN.ThentheissuerhostsystemreceivesanindicationfromtheHSMregarding whetherthePINthatwasreceivedaspartofthepaymentmessageisvalid.

2.8.3RelyingonPINVerificationValue(PVV)

AnothermethodofPINverificationisutilizingPINverificationkeys(PVK)and PINverificationvalues(PVV).

ThePVViscalculatedinamannerverysimilartotheCVVvaluesandis encodedaspartofdiscretionarydataonmagneticstripetracks1and2.Itsprecise location(i.e.,specificcharacterpositionsholdingthevalueaspartoftheDD vector)iskeptsecretaswellasthePVKthatisonlysharedwiththerelevant cardscheme.

TheissuerstorestheKEK-encryptedPVKsinadatabase.Uponreceivinga paymentmessage,theissuersendstheincomingencryptedPINblock,theincomingPVKandthenecessarykeydatatotheHSMwhichthensecurelyvalidates thePVKvalue.

RegardlessofthemethodtheissuerprefersthePVVvalueisstillinusefor stand-inprocessing,duringwhichcardschemesauthorizerequestsonbehalfof theissuers.

2.9Transactiontypes

Varioustransactiontypescanbeperformedataterminal,physicalorvirtual. Thesecanbedividedintothreecategories—retail-relatedtransactions,cashwithdrawalsanddepositsandpaymenttransactions.

2.9.1Retailtransactions

Purchase isthemostfrequentandbasictypeofacardholdertransaction.During apurchase,thedesiredamountistypicallyauthorizedonlinebysending anauthorizationrequest.Theacquirerhosteitherreceivesanindication thatthetransactionistobepresentedforclearingorclearsthetransaction bydefault.Cardschemesimposelimitationsonthetimeintervalbetween authorizationandclearingofthetransaction,andencouragetimelyclearing(usuallywithinthreecalendardays).

Certaincardschemesexplicitlydistinguishbetweenbasicpurchasesand purchasesinthegamblingindustry,sincethelatterbearhigherriskof fraudandmoneylaundering.Gamblingtransactionsaresometimescalled unique or quasi-cash tofurtherthedistinction.

Pre-authorization

isatypeofauthorizationrequestwhenthetransactionis unlikelytobepresentedforclearingimmediately.Pre-authorizationsare usedwhenthefinalamountofthetransactionisnotknownorthedeliveryofgoodsorservicescomesatamuchlaterdate.Thisisparticularly sowiththerentalandlodgingindustryorwithretailerswhosegoodstake significanttimetoship.Considersuchexamplesastheuse-caseofahotel pre-authorizingasecurityamountfromaguest’scardoracustomfurniture shopperformingthetransactionforanordertobedeliverednextmonth— bothwoulduseapre-authorizationfollowedbysomesortoffinalization forthetransactionupondeliveryofgoodsorservices.

Accountvalidation

isatypeofauthorizationrequestwhenthereisnoimmediatepurchaseintentandnoactualtransactionisperformed,butratherthe cardnumberandotheraccountdetailsarebeingvalidatedforthepurpose offutureuse.Therequestistypicallymadeasapre-authorizationwith zeroamountandinmanysolutions,issuersreplytoitwitharesponse codeof85(“Noreasontodecline”)inadditiontothewidelyused00 (“Success”).(Seealsosection3.3.4).

Aworsealternativetothededicatedaccountvalidationoperationiscard pre-authorizationforaminimalamountofmoney(suchas$0.01).

Completion orcaptureisatypeoftransactionfollowingapre-authorization. Considertheaforementionedscenarioofacustomfurnitureshop.Inthat case,theamountofthepaymentispre-authorizedoncetheorderisplaced, butoncethegoodsareshipped,themerchantcanperformacompletion operationtofinalizethetransactionandexecutepayment.

Refund transactionsanoperationofcreditingfundstoacardaccountduetoreturnedproducts,cancelledservicesorpriceadjustmentsrelatedtoaprior purchase.Arefundcanbemadeforthefullorpartialamountoftheoriginalpurchase,andmultiplerefundsforthesamepurchasecanbemade.

Cardschemeruleslimittheamountofrefundtothefullamountofthe originalpurchasetolimitfraudandmoney-launderingrisks.However,it ispossiblethatavalidandcompliantbiggerrefundfortheoriginalpurchasemightbemadeincasedifferentcurrenciesareusedandthecurrency ratechangesaccordingly.

Reversal,eitherfullorpartial,isanoperationoforiginaltransactioncancellation.Reversalscanbecausedbytechnicalreasonsandbesentautomatically.Unlikerefunds,whichcreditfundsafterapurchase,reversalisauniversaloperationappliedtoadditionaltransactiontypesbesidespurchases. Forexample,itispossibletoreverseapre-authorization,apaymenttransaction(seebelow)orarefund.Inadditiontofinancialimplicationsonthe cardholderandthemerchant,reversalshelprecoupsomeofthefeesthat areapplicabletotheacquirer.Thusareversalofabalanceinquiry(see below)isalsoavalidpracticalscenario.

Perhapsthesimplestwaytocomprehendthedifferencebetweenareversal andarefundisassumingthecardholderbillingstatementperspective.A purchasefollowedbyarefund,wouldshowupinthecardholderstatement astwoseparatetransactions.Apurchasefollowedbyatimelyreversal doesnotappearinthestatementatall.Therearerulesandlimitations fortimingofreversaltransactions:schemeslimitthetimewindowduring whichthereversalmightbeperformed,orrequirethatareversalisonly sentwhilethetransactionhasnotbeenclearedyet.

Balanceinquiry

isanoperationduringwhichaninquiryissenttotheissuer andtheissuerrespondstoitwithbalancesofoneormoreaccountsthat areassociatedwiththecard.BalanceinquiriesareusedinATMsbutalso areusefulinPOSenvironmentswithprepaidcards.Uponidentifyinga prepaidcard,themerchantcansendabalanceinquirymessagetotheissuermanuallyorautomaticallytochecktheavailablecardbalance.That helpsavoidingunnecessaryauthorizationdeclinesasthemerchantcannotifythecustomeraboutinsufficientbalanceandadvisethemtoregardsplit tender.Analternativetobalanceinquiryispartialauthorization-inwhich issuerrespondstoaregularpurchaseauthorizationmessagewithaspecial declinecode,indicatingtheallowedpartialamountintheresponsemessage.Themthemerchant’sPOSsystemcanaskthecardholderforanother paymeanfortheremainderofthefullamount.

PurchasewithCashback isanoperationduringwhichacertainamountofcash isprovidedtothecardholderalongsidethepurchasedgoodsorservices. Thecardholdercanrequesttoreceiveanamountincashalongsidethepurchase.Thecashiswithdrawnfromthecardholder’saccountandhanded tothecardholderatthepointofsale.Thatisaconvenientwaytocombine

apurchasewithcashwithdrawalwithoutaccesssinganATMorauthorizingthewithdrawalseparately.Thistransactiontypeisapplicablemostly todebitcards.

Anarrangementorapromotionaloffer,inwhichtheissuinginstitution sharesasmallpercentageofthecardholder’snetexpenditures(purchases minusrefunds)withthecardholderinformofloyaltypoints,purchase discountorbymailinganactualcheque,isalsoreferredtoasapurchase withcashback.However,inthiscasethecashbackarrangementisbetween theissuerandthecardholder.Itistransparenttothemerchantandthecard acceptorandthesetransactionsaretechnicallybasicpurchasesandare indistinguishablefromtransactionsoncardswithoutcashback.

2.9.2CashWithdrawalsandDeposits

Withdrawal isaremovaloffundsfromanaccountincash.Thattypeoftransactionisperformedatatellermachineequippedwithacashdispenser ormanuallybyacashierequippedwithaterminal.Duringawithdrawal, thecardholdercanchoosetheaccounttypeassociatedwiththisparticular card,fromwhichthewithdrawalisgoingtobeperformed.Notallacquirersorissuessupportthisoperation.Thisoperationisimmediate.

Itdiffersfroma cashadvance orcashdisbursementtransaction,whencash ishandedovertothecardholderasanadvanceoncreditcardbalanceand canberepaidasalumpsumorininstalmentsatalaterdate.Emergency cashadvanceonalostcardisnotconsideredawithdrawal.

Withdrawalsandespeciallycashadvancesusuallybearhigherrisksof fraudandmoneylaunderingthanothertransactiontypes.

Deposit transactionisadepositoffundsatacard-associatedaccount,typically performedatanATM.Likeanyothercash-relatedtransaction,itbearsa highriskofmoneylaunderingorfraud.

2.9.3PaymentTransactions

Paymenttransaction,alsoreferredtoas originalcredit or creditfundtransfer, isamoneytransfertransactionduringwhichfundsaresenttothedesignated recipientbythemerchantorfromonecardholdertoanother.Therearetwotypes ofpaymenttransactions:business-to-cardholderandcardholder-to-cardholder.

Paymenttransactionsfrombusinesstoacardholder,alsocalled funddisbursements,aredirectedfrommerchantsorgovernmentinstitutionstoprimarily consumercardholders.Merchantscanusethesetransactionstoissuerebatesor delivergamblingpayouts.Governmentinstitutionsandcompaniescanusefund

disbursementstodeliversalariesorpensionsdirectlytoacardholderaccount. Financialinstitutionscanusepaymenttransactionstopayinsurancesordeliver loanstocardholders.

Althoughfrompointofviewofdirectionoffundsbothrefundsandfund disbursementssuchasrebatesaredebitingthemerchantandcreditingacardholder,therearesignificantdifferencesastowhenandhowtheyaresupposedto beused.Thatdependsoncardschemerules.Also,cardschemeandinterchange feesforthesetransactiontypesdiffer.Funddisbursementtransactionsareusually accompaniedbyextradetailssuchasfullnameandaddressofthereceiverofthe funds.

Paymenttransactionsor moneytransfers betweencardholderstransmitfunds fromonecardaccounttoanother.Unliketransferringfundsfromamerchant toacardholder,moneytransfertransactionincludestwoparts.First,thesender transfersthefundstothemerchantthatfacilitatestheoperationina funding transaction.Oncecompleted,themerchantthentransfersthefundstooneor morerecipientaccountswithseparatepaymenttransactions.

Therearestrictlegalandregulatorylimitationsonmoneytransfersdueto theirpotentialforfraud,moneylaunderingandotherillicituse.Apaymenttransactioncanbemaliciouslyusedtolaunderorintegrateillegalfunds.Itcanbeused asaconcealedgamblingpayoutinajurisdictionwheregamblingisprohibited,or evenutilizedtodefraudtheacquirerbankitself.Consequently,cardschemesrequresignificantadditionaldetailsaboutactorsinvolvedinpaymenttransactions. Thesedetailsareusedinfraudpreventionmechanisms.Inaddition,limitations ontargetcountriesandmaximumtransferamountsvarygreatlybetweenareas andjurisdictions.

2.10Point-of-SaleTypes,ConditionsandEntryModes

Capabilitiesoftheterminalandthecard,thetechnologyinusetotransferdata betweenthetwoandconditionsofaparticulartransactionallaffectthewaysin whichthetransactionisthenprocessedbyacquirers,cardschemesandissuers.

Aterminalcanbeattendedorunattended,resideonoroffcardacceptor premises,orhavedifferingdisplaycapabilities.Aterminalmayormaynotbe ableofcapturingthecard.Aterminalcanworkproperlyoritspinentrydevice (PED)maymalfunctionatthemoment.Atthesametime,acardmayormay notbepresentattheterminal,andsomaythecardholder.Thecarditselfcan containmagneticstripe,anembeddedchipandacontactlessNFCtransmitter,or amobiledevicemightbeusedinsteadofacard.Furthermore,readofthechipor magstripemaynotbefullyreliable.

Someoralloftheaforementionedterminalcharacteristics,paymeanand transactioncanbetransmittedasoptionalormandatoryfieldsaspartofevery transaction.Specificsofvaluesinusedependonaparticularimplementation.

Tonavigatethatessentiallymulti-dimensionalcomplexity,itiseasiertomove frommorecommonandsignificantPOScharacteristicstolesscommonones. Unlessexplicitlyspecifiedotherwise,allmentionsof“card”inthissectionrefer toacardaswellasamobiledevicecapableofthespecifictechnology.

2.10.1DataTransferMethods

Datatransfermethod isthemeansbywhichdataistransferredorexchanged betweenthecardandtheterminal,assupportedbytheterminal.Thedatacan betransferredasaresultofphysicalcontactbetweenthecardandthedevice (“contact”)orbyproximity(”contactless”)3.Intheformercase,theterminal willbeequippedwithachipreader,amagneticstripereader,orboth.Inthe lattercase,theterminalwillcontainaproximityreaderonly.

Thecardcan,inturn,containachip,amagneticstripeandanNFCmodule.

2.10.2DataFormats

Dataformat describesahigh-levelsetofdatarepresentationrequirements. Theacceptableterminologyreliesontechnologiesthatfirstintroducedtherequirements,whichcreatessomeconfusion.Thedatacanberepresentedas “Magstripe”or“EMV”,withthelatterreferringtofull-gradeEMV.Combined withtheaboveoptionsofdatatransfermethods,thisyieldsfourpossiblemajoroptionsforacard-presenttransaction:“EMVcontact”,“EMVcontactless”, “Magstripecontact”and“Magstripecontactless”:

EMVcontact. Theoptionisnotsupportedbymobiledevices.Incaseofan EMVcontacttransaction,thecardisbeinginsertedintoachipreader. Theoptioncanalsobereferredtoasa“chipanddip”orsimply“EMV chip”transaction,withthelatterasacommonbutanimpreciseterm.An EMVcontacttransactionconditionimpliesacardequippedwithachipto beinsertedintothereader.FullcryptographicEMVexchangetakesplace andanoutgoingmessagecontainsICCdataindataelement55(ICCdata) andTrack2dataindataelement35(Track2data).

EMVcontactless. TheoptionissupportedbyNFC-capablemobiledevices,the architectureofwhichallowsforasecureelementtowhichtheissuerprovidedcryptographicdatacanbeloaded.Theoptionisalsosometimes referredtoassimply“contactless”.AnEMVcontactlesstransactionconditionimpliesthatacardequippedwithacontactlessantennaandanintegratedchipisplacedinfrontofthecontactlessreader(ortappedonit) andasuccessfulmessageexchangebetweenthechipandthereadertakes

3Certainly,thedatamaynotbeexchangedatallifcardisunabletocommunicatewiththedevice.In thatcase,attendedterminalswithkeypadsmayallowmanualkey-inofsomecarddetails.

placeoverradiowaves.Inthatcase,theauthorizationmessagecontains ICCdataindataelement55(ICCdata).

Magstripecontact. Theoptionisnotsupportedbymobiledevices.Itissometimesreferredtoas“magstripe”.Incaseofamagneticstripecontacttransaction,thecardisswipedthroughthereaderandthedatarecordedonits magneticstripeisreadbythereadinghead4.Theauthorizationmessage containsdataindataelement35(Track2data),dataelement45(Track1 data)orboth.

Magstripecontactless. TheoptionissupportedbyNFC-capablemobiledevices.Amagstripecontactlesstransactionconditionimpliesthatacard withacontactlessantennaoramobiledeviceisplacedinfrontofthecontactlessreader(“tapped”)andasuccessfulmessageexchangebetweenthe cardordeviceandthereadertakesplace.Inthiscase,though,thesolution emulatesmagstriperead,generatingandtransmittingtrack2datawithadditionaldynamiccryptographicelementsembeddedintothediscretedata portionofthetrack.Theauthorizationmessagecontainsdataindataelement35(Track2data)and,optionally,dataelement45(Track1data).

2.10.2.1TerminalCapabilitiesandConditions

Devicesusedtoacceptpaymenttransactionsvarygreatlyinconfiguration,architectureandabilities.Certainfeaturesofthesedevicesandsolutionsinvolving themaregovernedbyPCIsecuritystandards(forinstance,PINentrydevicesor PEDsshouldbesecureenoughtopreventPINcodetheft),someothersarecontrolledbycardschemebrandrules(prescribing,amongothers,designfeatures suchaslocationandprominenceofthecardschemelogo).

Cardschemesusuallyhaveaspecificsetofterminalcapabilitieswhichhave tobeproperlycommunicatedbothduringtheterminalcertificationprocess(see section2.10.3)andeveryauthorizationrequest.Furthermore,besidespermanent capabilities,aterminalmighthavecertaintemporaryconditions(forinstance, terminal’sPINpadmaymalfunctionandpreventcardholderverificationusinga PIN).

Althoughspecificconditionandrulesvarygreatlybetweenschemes,thefollowingsetcoversthemostcommoncasestheschemeswouldcareabout.

PANandPINEntryCapabilities

Coreterminalcapabilitiesincludethoserelatedtocarddatatransfermethods, supporteddataformatsandabilityforPINentry.

4A“contactmagstripe”readcanalsooccurinapart-gradeEMVenvironment,wherethechipand theterminalarebothcapableofafullchip-basedcontacttransaction,butthenetworkisn’t.Asthisisa transitionalstate,forthesakeofclarityitisnotextensivelycoveredhere.

Frompurelytechnicalpointofview,aterminalmayhavesomeorallofthe followingcorecapabilitiesforPANentry:

Keyentry istheabilitytoenterPANandexpirydataintotheterminalusinga keyboard.NotethatthisdoesnotimplytheabilitytosupportPINcodes, asPINentrydeviceshavestrictersecurityrequirements.Therefore,aterminalcansupportkeyentrywithoutbeingabletocapturePINssecurely.

Magneticstripe istheabilitytoentercarddatabyreadingtrackdatafromthe magneticstripeonthecard.

Chipreader istheabilitytoentercarddatabyinteractingwiththeintegrated circuitonitwithcontactdatatransfertechnology,i.e.theabilitytosupport “EMVcontact”transactions(seesection2.10.2).

Contactlessreader istheabilitytoentercarddatabyinteractingwiththeintegratedchiponthecardoracompatiblemobiledevice,usingwithcontactlessdatatransfertechnology,i.e.theabilitytosupport“EMVcontactless” transactions(seesection2.10.2).

Contactlessmagneticstripe -abilitytoentercarddatawithcontactlessdata transfertechnologybutwithoutchipdata-i.e.abilitytosupport “Magstripecontactless”transactions.Thisterminalcapabilityisspecified hereseparatelybecausesomeschemeshaveaseparatesetofdatavalues orflagstoindicateit.Someoftheschemesmandatecontactlessmagstripe supportforallcontactlessterminals.

AterminalmayalsohaveornothavethecapabilityforPINentry.Incasea terminaldoeshavesuchacapability,someschemeswouldrequirespecifyingthe maximumlengthofthePINsupported(upto12characters),asolderterminals maylimitmaximumPINlengthto4or6characters.

OtherInterfaceCapabilities

Aterminalcanhavesomeofthefollowingadditionalcapabilitiesthatmightbe madeknowntocardschemes:

Cardcapture istheabilityoftheterminaltoperformcardretentionorphysicallycapturethepaymentcardincaseafraudruleoraresponseby thepaymentschemeortheissuerinstructstodoit.Theabilityisalways presentinATMswherethecardcanbenotreturnedbacktotheterminal’s user.

Carddataoutput istheabilityoftheterminaltooutputdatatothecard.All EMV-compliantchipdeviceshavetheabilitytosendissuer-originatedinstructionstothechiponthecardwhichcantranslateintodatabeingupdatedontheICCstorage.Somecardschemesalsosupportindicationof magstripewritecapability(usedtoupdateTrack3,seesection2.4.3).

Terminaloutput istheabilityoftheterminaltooutputdatatothe user/attendant.Theabilityincludesadisplay,aprinterorboth.Onecansee thepotentialuseoftheindicatorforfrauddetection:obviously,aterminal withoutprintingcapabilitiesshouldneverreportsignatureasacardholder verificationmethod.

TerminalLocationandAttendance

Aterminalcanbeconsidered“attended”or“unattended”(alsosometimesreferredtoas“cardholder-activatedterminal”orCAT).Intheformercase,thereis anattendantemployeethatoperatestheterminalforortogetherwiththecardholder,whileinthelattercase,thecardholderoperatestheterminalwithnoassistancefromanattendant.

Aterminalcanbeownedbythemerchant,thecardacceptororthecardholder (thelatterisararecaseintheageofmodernelectronicandmobilecommerce).

Acardacceptor-ownedterminalcanbelocatedonoroffcardacceptor premises.

Toillustratepossiblebusinessscenarios,considerthefollowingcombinations 20ofterminallocationandattendance(itisassumedtobeownedbythemerchantorthecardacceptor):

Attended,onacceptorpremises—thisisthebasicscenarioofaterminalthatis locatedinastoreandisoperatedbyastoreattendant.

Attended,offacceptorpremises—inthisscenariotheterminalisownedbythe merchantandisactivatedbytheirrepresentativebutisnotlocatedinside thestore,forinstance,afieldtechnicianoratravellingsalesman,equipped withaPOSdevice.

Unattended,onacceptorpremises—inthisscenarioaterminalsuchasaparkinglotmachineoravendingmachineislocatedoncardacceptorpremises, butisactivatedbythecardholder.

Unattended,offacceptorpremises—inthisscenario,aterminalislocatedoutsidethecardacceptorfacilities.Agoodexampleisanetworkofvending machinesthatisdeployedinvariouslocationsoutsidethemerchant’smain facility.

TerminalCategories

Inadditiontotheaforementionedspecificcapabilitiesofterminals,schemesoftendefineterminalcategories.Aterminalbelongingtosuchacategoryhasa predefinedsetofcertaincapabilitiesandhastransactionacceptancerulesassociatedwithitscategory.

Forinstance,itiscommontodefinedmobilePOSormPOSasaseparatecategory.AnmPOSconsistsofamobilephoneortabletwithasupport-

ingapplicationandaPED(anexternalPINpad)usuallycontainingnecessary chip/contactless/magstripereaders.

Cardschemesusuallydefineairlineon-boardpurchaseterminalsasaseparate terminalcategoryforin-flightcommerce.Eventhoughaterminalofthiskindcan supportanydataformatortransfermethod,duetoverylimitedconnectivityon boardaplaneinflight,alltransactionsareauthorizedofflinebytheterminaland arelatertransferredtoschemesforclearing.

UnattendedterminalsareclassifiedbasedontheavailabilityofaPINpad, withunattendedtransactionsonterminalswithoutaPINpadbeinglimitedtoa maximumamount.

Automatedfueldispensers,tollboothsandmasstransitterminalsarealsodividedintodifferentcategoriesduetospecificsoftransactionprocessingonthese typesofdevices.Fueldispensersrequireaninitialauthorizationofthepayment cardwhilethefullamountofthepurchasedependsonthevolumeofpumped gasolinewhichisinitiallyunknown.

Tollboothsandmasstransitterminalshaveverystrictrequirementsfortimeit shouldtaketoauthorizeatransactionandperformasortofdelayedauthorization withcardissuersviaschemenetworks.Acardmightbecomeblacklistedandnot acceptedonaterminalofthiscategoryanylongeriftheinitialpaymentislater declinedbytheissuerandthecardholderhadafreeride.However,thiscalculated riskisconsideredpreferabletoabigqueuebuildingup,shouldeachtransaction actuallybeauthorizedonline.

TransientTransactionConditions

Asmentionedpreviously,besidespermanentcharacteristicsofaterminalitmay beinatransientcondition.Also,theenvironmentinwhichtheactualtransaction takesplacemaysometimesbereflectedindataelementsthataresentaspartof authorizationrequest.

Atthetimeofthetransaction,thecardandthecardholdermaybothbeeither presentorabsentatthephysicalterminal.Althoughmostofcard-not-present transactionsarehandledasmail,telephony,e-commerce,standingorderorrecurringpayments,itisstillpossibleto,say,performarefundinthecardholder’s presencewhentheydonothavetheiractualphysicalcardonthem.

Incertainsolutions,incaseswhentheshopattendantsuspectsfraudbutcannotretainthepaymentcardinasafemanner,therearemeanstoindicatethesuspiciontothepaymentnetworkandtheissuer,i.e.,thetransactioncanbemarked as“suspectedfraud”.

ThePINpadcanbepresentattheterminalbutnotfunctionattheparticular momentwhenthetransactionisprocessed.Thisconditionisindicatedseparately fromterminalpermanentcapabilitytoprocessPINcodes,sothatthereisaclear distinctionbetweenaterminalthatisnotcapableofhandlingPINentryatalland aterminalthatisnotcapableofhandlingPINentryatthisparticularmomentas anexceptionalcondition.

Besidestheterminalconditions,transientconditionsapplytotheprocessof carddatatransfer.Forinstance,thechipreadmightbecompletedbutisnotreliableorcontactlessdatatransferisnotsuccessfullycompleted.Theterminal mightdecidetoallowprocessingofthemagneticstripeinsteadoftheintegrated chip,duetoinabilitytocommunicatewiththechiporamalfunction.Themagneticstripeitselfmaynotbereliable,butTrack2datacanstillberetrievedfrom it,etc.

EntryModes

Thedatatransfermechanismandtherelatedtransientconditionsoftheterminal andthecardthatappliedatthetimeofinteractionareotherwisereferredtoas “POSentrymode”.Thesetofvalidvaluesandassociatedbusinessrulesvary betweenimplementations,however,commonvaluesandgroupingscanbefound inthedescriptionofDataElement22—seesection3.3.4.

2.10.3TerminalCertificationProcess

APOSdevicemustconformtoseveralstandards,dependingonjurisdictionin whichitoperatesanddependingonthePOStype.

Forexample,ifthedeviceiscapableofPINentry,cardschemeswillrequire aPCIPTS(PinTransactionSecurity)certificationofthedevicetobeperformed. AdevicesoldordeployedinEuropecertainlyrequiresaCEmarking,todeclare itsconformancewithEuropeanhealth,safetyandenvironmentalrequirements. AdevicewithwirelesscapabilitiesintendedforsaleintheUSneedsanFCCtest, andsoon.

Beyondthelistofstandalonecertificationsattestingtoterminalcompliance withaplethoraoflawsandstandards,priortodevicedeploymentforactualprocessinginaliveenvironment,ithastoundergoasortofend-to-endintegration testusuallyreferredtoas“cardschemecertification”.

Thegoaloftheprocessistocertifythedeviceforcorrectprocessingofcard transactionsinthespecificenvironment,includingconnectivitytotheacquiring hostand,throughit,toacardscheme.Achangeinhostsystemoranewterminal deviceusuallymandatesare-certificationofthesolution.

Suchacertificationprocessinvolvesutilizationoftestcards,availablefrom cardschemesorfromthird-partyvendors.Thetestcardsareusedtoexecute testswhichareprescribedbyeachschemeseparately.Thehostsystemcanbe connectedtoasimulatororpluggedintoatestenvironmentofthecardscheme.

Dependingonthebusinessenvironment,thecertificationcanbeperformedat theinitiativeofaPSPthatwishestodeploytheirterminalaspartofanintegrative solutionprovidedtobrick-and-mortarstores,orbyamanufacturerthatwishesto sellPOSdevicesdirectlytomerchants.

Aspartoftheprocess,oncethetestsonthePOSdeviceareexecuted,thelogs generatedduringtestingaresubmittedtocardschemesforverification.Insome

cases,alivetestperformedbyacardschemeengineermaybepartofthescheme requirements.

2.11Card-Not-PresentPoint-of-SaleTypes, ConditionsandEntryModes

Inthe“card-not-present”environmentPOSisavirtualconceptasthereisusuallynophysicaldevicethatisutilizedtointeractwiththecard.Asitispossible toprocesstransactionswithoutthecardonphysicaldevices,too,thecard-notpresentenvironmentreferstoprocessingoftransactionswhenthecardcannotbe presentbydefinition,ratherthanphysicallyabsentforaminorityoftransactions.

Thecard-not-presentvirtualPOSenvironmentscanbedividedintothefollowingcategories:

Mail/faxorder—referringtousecaseswhenPANnumbersandexpirydatesare sentbythecustomerviamailorfax5.Forinstance,adirectmailorder whenthecustomerismailingbacktheorderformisconsideredamail order.

Telephonyorder—whenthePANiscommunicatedbythecardholdertoaphone representativeorviaanIVR/ARUsolution,eitherbypressingphonebuttonsorusingvoicerecognitiontechnology.Forinstance,dialingintobook amovieticketwhenthecardnumberiscommunicatedwithDTMFsignalsordictatingthecardnumbertoanoperatorareconsideredtelephony orders.

Thesetwomodesarejointlyreferredtoas MOTO (MailOrder/TelephonyOrder) andarenotalwaystreatedseparatelybycardschemeprotocols.

e-commerce—whenthePANiscommunicatedbythecardholderelectronically overtheInternet.Asmanyprocessorsoffermerchantselectronicremote interfaces,includingbrowser-basedones,totypeinMOTOorders,itisimportanttoemphasizethate-commerceconditiononlyappliesincasecard dataiscommunicatedbythecardholderdirectlytocardacceptorsystems.

Merchant-initiatedtransactions—isacommontermforthefollowingthree environments,inwhichaparticulartransactionisnotinitiatedbythecardholderbutratherbyamerchantsystem.

Standingauthorization—referstoconditionswhencardholderinformationis keptonfilebythemerchant,acquirerorprocessorandcanbeusedto performad-hocornon-periodiccharges.Forexample,anonlinestorecan

5

Mailordershadreceivedanobviousboostwiththeascentofpaymentcardsinthelate1950sand pre-dateelectronicterminals.

associateastoredcardnumberwithacustomeraccount,thenalloweasier checkoutandpaymentbyenablingthecustomertouseastoredcard.This typeofconditionisalsoreferredtoas“cardonfile”.Noteveryscheme handlesitasaseparatetransactioncondition—someofthemstilldefine theaforementionedexampleasane-commercetransaction.

Recurringtransaction

—referstoacasewhenthecardisstoredonfileandthere isaperiodicbillingsuchasamembershipfeeorotherregularlyscheduled chargeinvoked.

Installmenttransaction—referstoatypeofrecurringtransactionwhenthespecificpaymentisapartofalargertransaction,forinstance,whenalarge purchaseismade.Dependingonthefundingarrangement,installments canbeprovidedbythemerchant,theacquirerortheissuer6.Notevery solutionisabletodistinguishebetweenrecurringandinstallmenttransactions.

6Incertainregionstherearecustomandspecialinstallmentschemesinwidespreaduse.Forinstance,in Japanitiscustomarytobreakpaymentsforlargepurchasesintoinstallmentsthataretiedtotwotraditional semi-annualbonusespaidtoJapaneseemployees.

3.1Introduction

Despitethevarietyofpaymentmeansandmethods,thereisbasicallyasingle familyofcloselyrelatedandverysimilartechnicalprotocolsatthebackbone ofthepaymentindustry.Essentially,therearethreemandatoryphasesandone optionalphaseinprocessingofapayment.Theyareauthorization,clearing,settlementanddispute(thelatterisanexceptioncase,butafrequentone).

Theauthorizationandclearingofpaymenttransactionsareperformedusing twoprincipalmethods—withasinglepaymentmessageorwithtwopayment messages.Theformermethodissometimesandwillbehereinbereferredtoas SMS(SingleMessageService)withthelatterbeingreferredtoasDMS(Dual MessageService).

IncaseoftheSMS,asinglepaymentmessagerequestsauthorizationofa certainamountandpresentstheauthorizationforclearing.Themethodiswidely usedinATMs,whereacashdisbursementisirreversible.Ithasadvantagesover theDMS,whichismorehistorical,inseveralaspects.TheSMSresponsemessagetypicallycarriesinformationthataidsacquirersinreconciliationoftheir accounts,includingpreciseinterchangefeesandcurrencyconversionrates,ifapplicable.Suchamethodofpaymenthasthefunctionalbenefitsofbeingatomic (onemessage,onepaymenttransaction)andhavingasingletechnicalprotocol insteadofmultipleones(sincetheclearingpartofDMSvariesbetweencard schemes).

IncaseoftheDMS,apaymentmessagerequestsauthorizationofapurchase butdoesnotpresentitforclearing.Theclearingpartofthetransactionisdone witheitheraseparateonlinemessage,or,morefrequently,bytransmittingpresentmentsoftransactionsinabatchfile.

Whileonlineauthorizationsaretypicallyperformedwithmessagesthatconformtoasharedstandard1 (adialectofISO8583protocol),batchclearingfiles canvaryintheirformatsignificantlybetweencardschemes.Topresenttransactionsforclearing,aninstitutiontypicallysubmitsoneormoreclearingfilesto cardschemesbeforecertaincut-offdeadline.Thetimingoffilesubmissionaffectsthebusinessdayonwhichitscontentsareconsideredpresented—thisdate issometimesalsocalledthe“ProcessingDay”or“CentralProcessingDate”.

Naturally,thecut-offtimedifferspercardscheme,butinadditionacard schemecanprovidemultiplesettlementservices.

Thesettlementphaseoftheprocessinvolvesbanktransfersandtheexchange ofaccompanyingreports.Cardschemesettlementrulesvarygreatly:ascheme cansettletheentireamountofadailysubmissioninfiveorevensevenbusiness daysordecidetosettleintra-country,intra-regionandinter-regionaltransactions atdifferentspeeds.Forinstance,domesticsettlementinIceland(transactionsthat areperformedbyIcelandiccardholdersatIceland-incorporatedstores)isonthe sameday,whileapaymentperformedby,forinstance,anAmericancardholder couldbesettledwithinthreebusinessdays.

Thecardholderortheissuinginstitutioncandecidethatacertaintransaction waspresentedinerroror,worse,isnotalegitimaterequestoffunds.Theformer canhappenifduetoatechnicalglitch,suchastheacquirer’ssystemhadsubmittedthesametransactiontwice,whilethelatterispossiblewhenacardhasindeed beenskimmedorthemerchanthasnotsuppliedthegoodsbutyetattemptstocollectthepayment.As,quiteliterally,thedisputeprocessmeansadisputebetween thecardholderandthemerchant,handledand/orinitiatedbytherespectivebanks orentities,itusuallyallowsforawell-definedexchangeofdocumentationand mutualclaimswithanabilitytoappealtothecardschemeforthedispute’sfinal resolution.ItisworthnotingthatinlocationslikeJapan,aslongasdomestic

1WithnotableexceptionofthelegacyCAFISprotocolinJapan.

transactioninterchangesstayoffthegridofglobalcardschemes,partiesprefertodiscussthedisputedtransactiondirectly(by,forinstance,arepresentative oftheissuingbankcallingtheacquirerorviceversa)insteadofembarrassing themselveswithaformalcard-schememediateddispute.

3.2AuthorizationServiceMessages

Aswasalreadyimpliedbeforehand,thetransactionauthorizationbytheissuer bankorbythecardschemedoesnotnecessarilyconstituteitsapproval.Incaseof aDual-MessageService,anauthorizedtransactionmeansthatitcanbepresented forclearingwhichcanbehonoredorrejected.

Themajorityofcardschemesworldwiderelyonpaymentauthorizationprotocolswhicharedialects(customizedversions)ofaprotocolgovernedbyISO 8583standard.Theseprotocols’messagescanbegroupedintotwocategories: cardholderandnetworkmessages2

Acquirers,interchangenetworkservicesandissuersusenetworkmessages toestablishorteardownsessions,toexchangekeys,testthecounterpart’sresponsivenessorcommunicatefileupdates(thelatterfeatureisusedforstand-in processingbypaymentnetworks).

Cardholdermessagescanbeusedtoperformpurchases,pre-authorizations, withdrawals,deposits,refunds,reversals,balanceinquiries,paymentsandinteraccounttransfers.

3.3ISO8583MessageStructure

CardschemesutilizecustommodificationsofthestandardISO8583protocol. Suchmodificationsarealsocalled ISOdialects.Inthischapter,somevariations oftheISO8583standardsalongsidethestandardstructurearediscussed.Forthe sakeofbrevity,theISO8583protocolwillbereferredtosimplyasISO.

AnISOmessageconsistsof:

header carryingmetainformationregardingthemessage.

messagetypeindicator (or messagetypeidentifier),abbreviatedasMTIor MTID,whichdescribesclass,typeandsourceofthemessage.

bitmap indicatingwhichdatafieldstoexpectintherestofthemessage.

datafields (ordataelements)encapsulatingmessagedata.

2Technically,filemanagementmessagesshouldbeaseparatecategory,butanacquirerdoesnotencounterthem

Figure3.1:MTIDstructure

3.3.1MessageHeader

EachISOmessagecontainsaheader.Theheadercanbetrivial,containingonly thefullbytelengthofthemessage,ornon-trivial,carryingmultipleadditional datafieldswithroutingandprotocoldetails.

Non-trivialISOmessageheadersusuallycontainroutinginformationinform ofstationorinstitutionidentifiers,aseparatefieldforheaderandbodylengths andaspecialfieldfor rejectcode.Incaseswhenthemessageispoorlyformatted butitsheaderisatleastlegible,somecardschemescanrespondbymirroring backtheoffendingmessagebutpopulatingtherejectcodethatindicatesthefield thatisinerrororpointsatconflictingvaluesfoundinseveralfields.Insuch casescardschememanualscontaintableslistingrejectcodesandtheirmeanings.Othercardschemeprotocolsmandateresponsewithafullvalidresponse message,allocatingspecialdatafieldorfieldstoelaborateontheerror.

3.3.2MessageTypeIndicator

EachISOmessagenecessarilycontainsamessagetypeindicatororMTID.The MTIDisafour-digitcodetransmittedasabinary-codeddecimal,specifyingthe versionoftheISOprotocol,messageclass,functionandorigin.Althoughin laterversionsoftheISOprotocolallfourdigitshavespecialmeaningaswellas awell-definedsetofvaluesandcanalsovarybetweenmessages,frompractical pointofviewitiseasiertothinkofMTIDasaconcatenationoftwotwo-digit values:themessageclassandthemessagefunction(see Figure3.1).MTID’sfirst digitspecifiestheversionoftheprotocol.Thethreemostcommonvaluesofthe firstdigitcorrespondtorevisionsofISO8583whichareshownin table3.1:The 1978revisionoftheISOprotocolisthemostcommononeintheindustry.For thesakeofsimplicity,itisassumedforallthefutureexamplesofISOmessages.

Table3.1:FirstdigitofMTIDandISO8583revisions

ValueDescription 01978revision 11993revision 22003revision

MTIDsecondspecifiesthemessageclass.Someofthevaluesforthemessage classinclude:

1authorization. Thismessageclasscontainsauthorization-relatedmessages andismainlyusedindual-messageprotocols.Purchase,pre-authorization, refundorapaymenttransactioncanallresultinoneorseveralauthorizationmessagesinthepaymentnetwork.Anauthorizationmessageisonly partofapaymenttransactionandasingleexchangeofmessagesofthis classdoesnotsufficefortheactualpaymentorfundtransfer3 .

2financial. Thismessageclasscontainsfullfinancialmessagesandamessage exchangeofthisclasscancauseanactualmovementoffundsifapproved. Thismessageclassisusedinsingle-messageprotocols.

4reversal. Thismessageclasscontainsmessagesthatreversemessagesfrom otherclasses,inparticular,authorizationandfinancialmessages.This messageclassisutilizedinbothsingle-anddual-messageprotocols.

8networkmanagement. Thismessageclasscontainsmessagesthatfacilitate thesessionestablishmentandteardown,protocol-levelkeepalivemessagesandisalsousedforkeyexchangeinsomedialects.

MTIDthirddigitspecifiesamessagefunction.Commonvaluesofthedigit are:

Thedifferencebetweenarequestandadviceisbestdescribedasthedifferencebetweenaskingandtelling.Intheformercase,apartyrequestsauthorizationofanoperation.Inthelattercase,apartyadvisesthatanoperationhasbeen 3Although,sincemostprocessorsandschemeschargepermessage,suchanexchangestillincursfees andcosts.

performed.Consideranexampleofacardholder’spre-authorizationperformed atahotel.Sincetheapproximateamounthasalreadybeenpre-authorizedbythe issuer,itispossiblethattheactualpaymentissentasanadvicemessage.

MTIDfourthspecifiesthemessageorigin.Therearemultiplevalidvalues forthedigitinvariouseditionsoftheISO8583protocol.Weonlyconsider 0acquirer-originatedmessageand1acquirerrepeatoutofthem.Theformerindicatesanoriginalmessage,andthelatterindicatesthatanattemptisbeingmade toresendthepreviousmessagetowhichtheresponsehasnotbeenreceived.

Considervariouscombinationsofmessageclassesandfunctions(assuming ISO85831978edition)aslistedin table3.2.

Somepossiblescenariosincludingmessagesinvolvedarelistedbelow.The scenariosareprovidedforillustrationonlyandspecificcardschemeprotocols willprobablydifferinsomeofthesecases.

Sessionsetupandteardown

Anacquirer,settingupasessionwithacardscheme,sendsa0800messageto itsnetwork—“Networkmanagementrequest”.Thenthecardschemeresponds witha0810message—“Networkmanagementresponse”,indicatingsuccessful sign-ontothenetwork.Uponshutdownoftheconnection,theacquirersendsa 0800messageandreceivea0810messageinresponse.

Purchase

ADMSacquirersendsa0100(authorizationrequest)tothenetworkwhichin turnforwardsittotheissueraskingtoauthorizetheamountofthepurchase.The issuerrespondswitha0110(authorizationresponse)that,inturn,isforwarded totheacquirer.

Pre-authorizationandcompletion

ADMSacquirerwouldsenda0100(authorizationrequest)messagetopreauthoriseapurchase.Themessagewouldgetforwardedtothecardissuerand prompta0110(authorizationresponse)messageinreturn.Incasetheoriginal

requestisauthorisedbytheissuersuccessfully,theacquirer—atalaterstage— sendsa0220(financialadvice)messagetoindicatethecompletionofthepurchase.The0220messageisforwardedtotheissuerthatrespondstoitwitha 0230(financialadviceresponse),acknowledgingthereceivaloftheadvice.

Purchasecancellation

Anacquirerfirstsendsan0100(authorizationrequest)messagetoperforma purchase,towhichtheissuerrespondswitha0110(authorizationresponse). Then,themerchantthatisservicedbytheacquirercoulddecideoncancelling thetransactionif,forinstance,itwaserroneouslysentduetoasoftwarebugin themerchant’se-commerceplatform.Thentheacquirersendsa0400(reversal request)messageandreceivesa0410(reversalresponse)inreturn.

3.3.3Bitmap

Thedatafields(ordataelements)presenceinaISOmessagecanvarygreatly betweendifferentmessagetypes.Assuch,thedataelementspresenceorabsence isdefinedbyabitmap.AnISOmessagecancontainone,twoorthreebitmaps, calledprimary,secondaryandtertiaryorextendedbitmap.

Mostmajorcardschemesuseuptotwobitmapsintheirmessages,andthe primarybitmapmustbealwayspresent.

Asinglebitmapconsistsof8bytes,inwhichbitsarenumberedfromleftto right,startingfrom1.Thus,aprimarybitmapcontainsbits1through64,asecondarybitmapcontainsbits65to128andanextendedbitmap,correspondingly, coversdataelements129to192.

Thefirstbitofprimaryandsecondarybitmaps(bits1and65)donotcorrespondtoadataelementbutindicatethepresenceofasubsequentbitmap.

Considerthefollowingsamplebitmap: 822000000A000000.Itcorrespondstothefollowingstringofbits:

Thebitmaphasbits1,7,11,37,39set.Sincebit1isset,asecondarybitmap ispresentinthemessageandtheapplicationprocessingthemessageshouldread subsequent8bytesfromtheinputstreamandinterpretthemasabitmap.This particularmessagedoesnotcontaindataelement2(wherethePANisstored,see below),andisthereforelikelytobeanetworkmanagementmessagenotlinked toaparticularcardholderaccount.Furthermore,judgingbypresenceofdataelement39(theresultcode)thisbitmaplikelybelongstoaresponsemessage.

3.3.4DataElements

AnISOmessage’sdataelementscancarryaverydiversesetofdatatypesencodedinseveraldifferentways.SomedataelementsaredefinedbytheISOstandard,othersareconsideredproprietaryandcardschemessettheirownformat andusageforthefields.Proprietaryfieldscanhaveafixedpre-definedsetofsubfields,orasortoftag-length-value(TLV)subformatwherethesubfieldID(tag) isfollowedbythedatalengthandthenbyvalue.Oncertainoccasions,schemes useproprietarybitmapstoindicatewhichoptionalsubfieldsarepresentinaproprietarydataelement.Lastbutnotleast,itisnotunusualforanISOdialect messagetocontaindatainbothASCIIandEBCDICencodingssimultaneously.

Formats

Asmentioned,thereareseveraldataencodingformatsforISOdataelements. Thestandardnotationincludesthefollowingdefinitionsofvalidvaluesforthe elements:

a—denotesalphabeticcharacters—bothupperandlowercaselettersoftheLatin alphabet.AlthoughthesecanbeencodedinbothASCIIandEBCDIC,dependingonthefieldanddialect,nationalcharactersarenotusedinonline authorizationmessages.

n—denotesdecimaldigits.

s—denotes“specialcharacters”whichareprintablecharactersoftheASCIItable otherthanalphabeticornumeric.Quiteoften,the s notationcomeswith additionallimitationsorrequirementsforaparticularfield. 4

b—denotesbinarydata.ItisworthmentioningthatEMVdata,transmittedin field55,isdenotedas b andfurtherhasanadditionalsetofrulesonhow tointerpretthebinarycontents(seesection11.6).

z—denotesspecialformatsofTrack1andTrack2data(seesection2.4).

Thedefinitionscanbecombinedwhenitmakessense:forexample,there arefieldsdenotedasanorans(“alphanumeric”and“alphanumericandspecial characters”,correspondingly),but,obviously, b and z cannotbecombinedwith othernotations.

Length

ISOmessagefieldscanvaryinlength.Someofthemallowfixed-lengthvalues whichmustbealwaysfilledwithmeaningfulcharacters(forinstance,field14, thecardexpirationdate,isnumericandhasafixedlengthof4symbols),others haveafixedlengthandrequirevaluestobepaddedwithspaces(e.g.,field38,

4

Forexample,afieldwiththe s notationmayallowspacesbutcannotbeallblanks.

approvalcode—alphanumeric,hasafixedlengthof6butcancontainlessmeaningfulcharactersandcanbespace-padded),yetsomeothershaveavariabledata length.Avariablelengthcanbespecifiedeitherinbytesorinotherunits,such asnibbles(half-bytes)orbits,inwhichcase,therearepaddingrulesforfield values.Somecommonlengthnotationsare:

-digit(s)—fixedlengthnotation.Forinstance,theaforementionedexpirydate fieldcanbedescribedasn-4(numeric-onlydatafieldwithfixedlength of4).

..digit(s)or...digit(s)—variable-lengthnotationwithmaximumlengthspecified.Dependingonspecificsofaparticularfield,thestandardandthe dialectscontainrulesdeterminingthelengthordescribingpadding.

LLVARorHLVAR—variable-lengthfieldswhichcontaintwosub-elements: LL(single-bytelengthofthefield)andVAR(thedata).Thelengthis BCD-encodedand,therefore,anLLVARfieldcancontainupto99data units.

LLLVARorHLLVAR—variable-lengthfieldswhichcontaintwosub-elements, LLL(double-bytelengthofthefield)andVAR(thedata).Thelengthis BCDcodedandcontainsthreemeaningfuldigits.ItfollowsthatanLLLVARfieldcancontainupto999dataunitsandthevalueinitsLLLportion iszero-paddedfromtheleft.Forexample,a125bytelongfield55(binary) hasitslengthencodedas0x0125.

Padding

Paddingofvariable-lengthfieldscandiffer,butthereisaruleofthumbthat appliestomostdialects.Itisasfollows:ifavalueisalphanumericorspecial (anyof as, ans, ns fields),itisconsideredastringandispaddedwithspaces fromtheright.Ifthevalueisnumeric-only,itisconsideredanumberandis paddedwithzeroesfromtheleft.

Thus,avalueof“ABC”whenpopulatedinanalphanumericfieldwithtotal fixedlengthof4,isrepresentedas ABC^ (ˆbeingthespacecharacter)inacharacterencoding(seebelow),whileanumericvalueof123,whenencodedasaBCD value,istransmittedas 0123.

Encoding

Severaldata-encodingmethodscanbehighlightedintheISO8583realm.First andforemost,therearethecharacterencodings:ASCIIandEBCDIC.Numeric dataisalsorepresentedasBCD(binary-codeddecimals).Finally,aspartofa lateradditionforfull-gradeEMVtransactions,thereistheBER-TLVX.690format,setbyITU-T.

ASCIIstandsfor“AmericanStandardCodeforInformationInterchange”5 . Originallydevelopedasa7-bitformat,theencodinghasbeenwidelysuperseded

5MoredetailsonASCIIcanbefoundinsection11.3.

byUTF-8whichisbackward-compatibletoit.Althoughitwasextendedtoan 8-bitcodewhichhasseenmultiplenationalcodepages,theoriginal7-bittable ispredominantlyusedinmostpaymentapplications.

SpacecharacterinASCIIisencodedas0x20(32decimal),whiledecimal digitsaremappedtocodes0x30to0x39.Thus,abundanceof0x20valuesinan ISOmessageusuallyhintataspace-paddedfieldwhilebytesequenceslike 31 393633 indicateASCII-encodednumericsequences.

EBCDICstandsforEnhancedBinaryCodedDecimalInterchangeCode6 Originallydevelopedasa8-bitproprietaryformatofIBM’sSystem/360,ithad tobecompatiblewithexistingarraysofinput/outputdevicesandwasdesignedas anincrementalextensionofexistingpunchcardencodings.Itisstillbeingused inpaymentindustry.SometimescardschemerequiresusingEBCDICforalltext fields,inothercasestherequirementcoversproprietaryfields(whichroutinely yieldsISOmessagesinwhichsomedataelementsareencodedinASCIIand someinEBCDIC).

AspacecharacterinEBCDICisencodedas0x40(64decimal)anddecimal digitsareencodedinrange0xF0to0xF9.UppercaseLatinlettersoccupyranges 0xC1to0xC9,0xD1to0xD9and0xE2to0xE9.Thepresenceofbytesequences inwhichthefirstnibbleisC,D,EorFandthesecondnibbleisalwaysbetween 0and9hintsatapossibleEBCDIC-encodedcharactersequence.

BCDstandsfor“BinaryCodedDecimal”andisasimpleencodinginwhich numericalvalues,insteadofbeingrepresentedasabinarynumber,areencoded byallocatingafixednumberofbitstoeachdigit.InISO8583messagesthesocalledpackedBCDformatisused:asfourbitsaresufficienttorepresentnumbers from0to9,each4-bitnibbleisusedtocontainasingledigit.

Toillustratethethreeaforementionedencodings,considerthefollowingexample.

Thedecimalnumberof17471,representedbase16,equalsto443F16.If transmittedonthewire,and,therefore,representedinbig-endianornetwork byteorder,thebinaryvalueoccupiestwobytesexactlyascanbeseenabove, 443F.IfencodedinpackedBCDformat,thevalueoccupiesthreebytesandis representedas 0174717.InEBCDICandASCII,thedecimalvalueisencoded as F1F7F4F7F1 and 3137343731,accordingly.Considersomeother

table3.3.

12905

EBCDIC F1 F2 F9 F0 F5

7376 Binary 1C D0 7376 BCD 73 76 7376 ASCII 37 33 37 36 7376 EBCDIC F7 F3 F7 F6

BER-TLVorsimplyTLVencodingstandsfor“BasicEncodingRules— Tag/Length/Value”encodingandisameanstorepresentadatastructureina serializedformsuitablefordatatransfer.TheBER-TLVformatusedinpayments industryadherestoX.609standardbyITU-T.

Theencodingiscalled“tag-length-value”sinceeachelementofthedata structureisrepresentedbyanidentifier(ortag)followedbyvaluelengthand thenfollowedbythevalueitself.Thisallowspackingofanarbitrarysetofelementsinarbitraryorderintoasingledataelement.

TheEMVstandarddefinesasetoftagvaluesthatshouldbeusedfordataexchangebetweenpartiesinvolvedinanEMVtransaction.Forexample,tag5F34 correspondingtoPANsequencenumber,isdefinedashavingnumericvalueand anibblelengthof2(bytelengthof1).Thismeansthatasequencenumberof2 isrepresentedas 5F340102,withfirsttwooctetsarethetag(0x5F34),third octetrepresentslengthinbytes(0x01)andthefourthandfinaloctetisthevalue (0x02).

MoredetailsonBER-TLVformatcanbefoundinsection11.6.

KeyDataElements

TheISOstandarddefinesacoresetofdataelementswithspecificsemantics andformattingrulesbutalsoallowsforasignificantnumberofnationaland implementation-specificdataelements.Furthermore,eventhesamedefinitionof thedataelementinthestandardisinterpreteddifferentlybetweendialects.The followingsectionlistscommonfieldsandformatswhichdonotdiffermuchin theirinterpretationbycardschemes.

DataElement1—Bitmap ThedataelementisalwayspresentinanISOmessage,asitisrequiredtoparsetherestofthemessage.Detailsonthebitmapcan befoundinsection3.3.3.

DataElement2—PAN TheelementispresentinmostISOtransactions,excludingsomeadministrative/networkmanagementmessages.Thefieldformatis LLVAR,anditcontainsaBCD-encodedPANnumber.Thelengthisspecifiedin digits,ratherthaninbytes,andisalsoBCD-encoded.IncasethePANcontains anoddnumberofdigits,itispaddedfromtheleftwithzeroesbutthepadding doesnotcounttowardsthelength.AsthemaximumlengthofaPANis19digits,themaximumlengthofthedataelementis11bytes(1byteoflengthand

10bytesforthelongestpossiblevalue).ConsiderexamplesofPANsandtheir ISO8583encodingsin table3.4.Intherepresentation,lengthvaluesarein italics andthezeropaddingisin bold

DataElement3—ProcessingCode Theprocessingcodedataelementindicates thetypeoffinancialservicerequestedandthetypeofsourceandtargetaccounts affectedbyit.Theformatofthefieldisn-6,i.e.itisalwaysa6-digitBCDencodednumericvalue.

Thedataelementhasthreesubelementsandeachofthemhasalengthof2 digits.Subelement1correspondstothetransactiontype,subelement2indicates thesourceaccounttypeandsubelement3indicatesthetargetaccounttype.

Actualvaluesofprocessingcodesthatareinactiveusevarybetweenimplementationsindifferentcardschemes.Valuesof00,20and30forsubelement1 indicatebasicPOSpurchase,refundandbalanceinquiry,correspondingly,and valuesofallzeroesarethemostcommonforsubelements2and3.Inotherwords, animplementationshouldprobablyexpecttousevaluesof000000,200000and 300000forthoseoperations.However,thatmayvarypercardschemeandper geography.

DataElements4,5and6—Amounts Dataelements4,5and6aredefinedas “amount,transaction”,“amount,settlement”and“amount,cardholderbilling” correspondingly.

Thesefieldsshareacommonformat:theyarealln-12BCDfields,leftpaddedwithzeroes.Valuesinthesefieldsareunsignedintegersrepresenting amountsinacurrencythatiseithertransmittedinanotherdataelement(forinstance,transactioncurrency)orisimpliedaspartofmessagecontext(forexample,thecardholder’sbillingcurrency).

Thedecimalplaceintheamountfieldsisimpliedbycurrencyexponentwhich isgovernedbyISO4217standard.Acurrencyexponentexpressesthenumberof digitsafterthedecimaldotorthepowerof10bywhichtheintegervalueshould bedividedtoobtaintheexactamount.Mostcurrencieshaveanexponentof2 (forexample,USdollars,euro,Britishpoundsoryuanrenminbi);therearesome currencies,mostlyMiddleEasternones,thathavetheexponentof3(Omanirials

orKuwaitidinarstonametwo).Finally,incaseswhentheminorcurrencyunit doesnotexistorisnotinuse,theexponentis0(forexample,Japaneseyen).

Fields4,5and6differintheirusage.Field4,“amount,transaction”,isthe mostfrequentlyusedfield.ItcontainsthePOSorATMtransactionamountand isinitiallypopulatedontheacquirerside.Field6,“amount,cardholderbilling”, containstheamountwhichthecardholdershouldbebilledandisusuallypopulatedbythepaymentnetworkbeforethetransactionreachestheissuer.Field 5,“amount,settlement”,containstheamountoffundstobetransferredbetween theissueandtheacquirer(orviceversa,dependingonthetransactiontype).Ifin use,itistypicallypopulatedbythepaymentnetwork.

DataElement7—TransmissionDateandTime Thefieldcontainsthe timestampoftransmissionandnotthedateand/ortimewhentheactualtransactionwasperformed.Itispossiblethat,duetoofflineprocessingorotherreason,thetransactionwasperformedinthepastandistransmittedatadifferent moment.

Theformatofthefieldisn-10BCD,anditcontainsthetimestampinMMDDhhmmssformat,meaningthattwodigitsofthemontharefollowedbytwodigitsoftheday,24-basedhours,twodigitsofminutesandtwodigitsofseconds.

Forexample,atransactionthatwastransmittedonMarch4th,twominutes and13secondsafternoon,hasthetimestampvalueof 0304120213 inthe ISOmessage.

Timezoneofthetimestampdiffersbetweencardschemesandimplementations.

DataElements9and10—Conversionrates

DataElements9and10aredefinedas“Conversionrate,settlement”and“Conversionrate,cardholderbilling”, correspondingly.Theseelementsaccompanydataelements5and6incaseswhen theyarepresentandwhenthecurrencyofsettlementorbillingdiffersfromthe transactioncurrency.Inotherwords,someissuersmightseedataelement10,but dataelement9isquiterare.

Theformatoftheseelementsisn-8,BCD.Thefirstdigitofthefieldcontains“displacement”or“decimalindicator”,anumberfrom0to7indicatingthe

positionofthedecimalpointfromtheright.Theremaining7digitscontainthe actualrate.Considertheexamplerateof23.12032.Thedecimaldotislocated atposition5fromtheright,henceonthewirethevalueisrepresentedas 5231 2032.

DataElement11—SystemTraceAuditNumberorSTAN Thisfield’sformat variesbetweenimplementationsandISO8583protocolrevisions.Intheolder ISO8583standarditisn-6whilelaterversionsallowalphanumericandspecial characterstobeputinthisfield.

Itissetbythetransactionoriginatortouniquelyidentifyacardholdertransactionandallmessagesthatcompriseit.Forinstance,anauthorization,itsresponse messageandfurtherreversalandreversalresponsemessages(ifareversalevent occurs)shouldallcontainthesameSTANvalue.

WhentheSTANisnumeric,itcannotbeallzeroes.TheSTAN,combined withDE7(transmissiondateandtime)shoulduniquelyidentifytransactions sentonthesameday.However,ifthedailyvolumeofaparticularinstitutionis over1milliontransactionsforaparticularcardschemeandanolderISO8583 revisionisinusewiththepaymentnetwork,thesamevaluesinthefieldcanbe repeatedbythetransactionoriginator.

DataElements12and13—TimeandDateofLocalTransaction Inmostcases dataelement12isn-6BCDandcontainstimeinhhmmss24-hourformat, whiledataelement13isn-4BCDandcontainsdateinMMDDformat.However,certainimplementationsutilizedataelement12asn-12andrequireafull timestamptobepopulatedinthatfield.

Thisdataelementcontainsthedateandtimeofthecardacceptorlocation.In thecard-presentenvironment,thismeansthedateandtimeatthestorewhenthe actualtransactionwasperformed,setinthe localtimezone ofthecardacceptor (asopposedtodataelement7whichissentinascheme-definedtimezone).

ConsidertheexampleofatransactionthathappensinastoreintheEST timezoneatexactly1:15pmonMay18th,2012.Assumingbothdataelement12 and13areutilized,dataelement12shouldbesetto 131500,anddataelement 13shouldbesetto0518.

However,messagedataelement7accordingtothehypotheticalcardscheme rulesshouldbesetinUTC.Thatmeansthatthehourpartofthedataelement 7transmissiontimestampisbe18andnot13duetothe+5hourstimezone difference.Inadditiontothat,itispossiblethatthetransactionwassenttothe acquirerhostafewmicrosecondsbeforetheendoftheexactsecondandbythe timethehosthaspreparedthetransactionfortransmissiontothenetwork,the timeofthehostserveris18:15:01andthatalsowillbethevaluethatwillbesent indataelement7(0518181501).

Furthermore,itispossiblethatthetransactionwillbetransmittedaftera minutehasflipped(forexample,transactioncapturedat13:15:59.999butbythe timeitissenttoaschemeitis13:16:00),orafteradayoramonthhadchanged.

Inthecard-not-presentenvironmentthisfieldshouldbepopulatedbythe serverthatcapturesthetransaction—inaproper,compliantimplementation ane-commerceapplicationthathandlescustomerpaymentshouldtransmitits serverdateandtimeinitslocaltimezone.

DataElement14—Date,Expiration Thisdataelementholdsthecardexpirationdate,asstoredonthemagneticstripe,reportedbycardintegratedchipcircuit orenteredmanually.Thisfieldisn-4,BCDandtheexpirydateistransmittedin YYMMformat.

Thecardexpirydateisdefinedasthelastdayofthemonth.I.e.,ifthecardexpiresinMay,2015,itisvalidthroughthe31stofMayandisconsideredexpired onJune1st.

Cardschemestypicallydonotrequiretheirprocessorstodeclinetransactions basedonexpirydateofthecard.However,sincethevastmajorityofcardauthorizationswillbedeclinedpasttheexpirydate,mostprocessorsdeclinetransactionsonexpiredcardsatthefront-end,withoutsendingthemtopaymentnetworks.

DataElement18—MerchantType Inmostimplementations,thisfieldcontains theso-calledMCC(MerchantCategoryCode)—a4-digitindustrycodethatis assignedtothemerchantwhenit’saccountisopenwithanacquirer.Itsdefinition isn-4.

ThelistofMCCcodespartiallycoincideswiththelistof4-digitSICcodes (StandardIndustrialClassificationcodes)8,inparticular,inservicesandretail codegroups.In2004,theInternalRevenueServicehadadvisedtaxpayersto relyonmerchantcategorycodesinordertoidentifyreportablepaymentcard transactions.

However,whileSICallocatescodeperindustry,coveringindustriessuchas miningandmanufacturing,inthepaymentcardindustrycodeswereallocatedto majorairlines(3000-3299),carrentalcompanies(3351-3441)andhotelchains andresorts(3501-3790).InSICtheserangesareassignedtomanufacturingindustrieslikerubber/leather/concrete/electronicsandthelikes.

Thus,certaingenericMCCsco-existwithspecificones,astherealsoare genericcodesforairlines(4511),carrentals(7512)andhotels(7011).

WhiletheMCCtableisingeneralsharedacrosscardschemes,rulesunder whichtheyareassignedmaydiffer.Itfollowsthatsomemerchantsmighthave severaldifferentMCCsassignedaccordingtorulesofdifferentcardschemes.

8StandardIndustrialClassificationcodeswereintroducedintheUnitedStatesin1937.Althougha newer6-digitclassificationhadcamesinceintobeing,4-digitSICcodesarestillinusebyUSauthorities suchastheUSDepartmentofLaborOccupationSafetyandHealthAdministration.

Furthermore,insomecasesthesameoutletorterminalcanutilizedifferent MCCsbasedonthetypeofoperationperformed.Forexample,anautomated tellermachineistypicallyassignedMCCof6011(automaticcashdisburse)but itcansendtransactionswithMCCof4829(moneytransfers)providedthatit supportsthatfunctionality.

DataElement22—POSEntryMode Thedataelementvariesinlengthbetween implementations.Inmostcasesitisfullynumeric,upto4positionsinlengthand contains2or3meaningfuldigits.However,therearedialectswithsignificantly differentdefinitionsofthefield.

ThePOSentrymodedescribesthemethodusedtoenterthePANandthecard expirydateatthepoint-of-service.Insomecaseswhenanelectronicterminal isused,thefieldcanalsocontainanindicationregardingterminalPINinput capability.

POSentrymodesinusebydifferentschemescanbelargelygroupedasfollows9:

Unknown/noterminalused—isthevaluecorrespondingtotransactionswhen thePAN/expirydatecapturemethodisunknownorwhenthetransaction wasapaper-basedone.Ineithercase,itiseitherararemethodoravery baddefaultvalue,sinceotherPANentrymodesaremoreappropriatefor overwhelmingmajorityoftransactions.Acommonvalueforthisentry modeis 00

Manual/keyentry—inthecard-not-presentenvironments,thisvalueshouldbe usedwheneverthePANismanuallyenteredbyanoperatorafterhaving beentransmittedtothemerchantbycardholder—inotherwords,inmail order/telephoneorder(MOTO)transactions.Inthecard-presentenvironments,thisvalueisusedwhenthesalesattendanttypesinthePANnumber manuallyintothePOS—usuallyafterattemptstohavethecardreadelectronicallyfail.Acommonvalueforthisentrymodeis 01.

Magneticstriperead/magstripefallback—severalpossibleconditionscan leadtochoosingthemagneticstripereadasaPANentrymethodfora paymentcard.Itispossiblethataterminalisonlyequippedwithamagneticstripereader,or,alternatively,aterminalisEMV-capablebutthecard hasnochipembeddedintoit.Insomecases,theconditionsofthemagneticstripereadaredistinguishedfurtherasreliableandpartial.Sucha “basic”magstripereadistypicallyindicatedwithvaluesof 02 or,more commonly, 90.

Anotherpossibleconditionisthe magstripefallback,whenanattempt toreadachip-capablecardonachip-capableterminalhasbeenmadebut failed.Thisconditionisusuallydenotedbythevalueof 80

9

Thecodeslistedinlinearetheonesusedintheindustrymostfrequently.Asmentioned,inthecase ofaspecificimplementationvaluesmayvarysignificantly.

PaymentnetworksandissuersexpectfullTrack1and/orTrack2data incasethePANisenteredusingamagneticstriperead.

Integratedcircuitcardread—thisconditionindicatesthatacontactchipread hasbeenperformedattheterminaltoenterthecardPANandexpirydate. Likewithamagneticstripe,unreliableICCreadsareoftendistinguished fromreliableonesbyaseparatecodevalue.Thisconditionisusuallydenotedbythevalueof 05

Electroniccommerce—thisconditionisoftendefinedas“PANauto-entryusingelectroniccommerce”butisusedtoindicatesuchconditionswhenthe PANismanuallyenteredbythecardholderaswell.Itisusedforsuch e-commercescenariosasaone-timepurchase.Card-on-fileone-timepurchasesandrecurringtransactionsandinstallmentswerealsopreviously usedwiththisPOSentrymode,butgotassignedseparateentrymodevaluestobetteridentifythem.Thee-commerceconditionisusuallydenoted byvaluesof 09 or 81.

Contactlesschip—thisconditionisusedwhenthePANisenteredviathecontactlessdatatransfermethod,bututilizingthechiponthecardand,consequently,passingfullICCdata.Theconditionisalsopossibleifamobile devicewhichisequippedwithasecureelement,andthereforecapableof performingfull-gradeEMVtransactions,isusedforpaymentatthepoint ofsale.Thisconditioniscommonlyencodedwiththevalueof 07.

Contactlessmagneticstripe—theconditioncorrespondstosituationswhenthe PANdataisauto-enteredusingcontactlessdatatransfermethodbutundermagneticstripedatarules.Acontactlessmag-stripereadcanoccur eitherwhenthecardorcardreaderdonotsupportfull-gradechipcontactlesstransactionorwhenamobiledevicewithnosecureelementis usedtoperformacontactlesspaymenttransaction.Inadditiontovarious implementationsofcontactlessmagneticstripe,theintroductionofpaymentnetworktokenizationhasbeenaccompaniedbytheintroductionof conditionsindicatingPANauto-mapping(applicabletoissuersonly).The contactlessmagstripeconditionisusuallydesignatedwiththevalueof 91, withseveraladditionalcodesinusebydifferentimplementations.

Otherconditions—thatarenotparticularlycommonbutaresupportedbymost dialectsincludeauto-entrywithabar-codereaderoranopticalreader.

DataElement23—CardSequenceNumber Theformatofthiselementisn-3. ItholdsapackedBCDvalueofthecardsequencenumber. ThevalueismandatoryinEMVfull-gradechiptransactions.Insuchcases thechiponcardprovidesthevalueinabinarybyteandtheterminalisresponsible

toencodeitinBCDformat.LikeallBCDvalues,itisleft-paddedwithzeroes. Thus,forexample,ifachipreturnssequencenumberof0x0A(decimal10),it shouldbeencodedinthisdataelementas 0010

DataElement25—POSConditionCode

Theelementisnotconsistentlyused byvariousimplementations.However,whenschemeselecttoencodetheseconditionsindifferentandoftenproprietaryformattedfields,theoverallsetofpossibleconditionsislargelythesame.

DataElement35—Track2Data ThiselementwasoriginallydesignatedtocontainfullTrack2dataexactlyasreadfromthemagneticstripe(seesection2.4.2 fordetails).However,additionalapplicationsforthefieldhaveemerged,which doretainthesameoriginalfieldformat.Inparticular,chip-basedtransactions generateTrack2dataaswell.

Exactencodingofthisdataelementdependsontheimplementation.Incertaincases,theelementisencodedasans-37andboth‘D’and‘=’symbolsare allowedasfieldseparatorcharacters.Insomeotherimplementations,thefieldis n-37withtheexceptionof0xD(decimal13)beingallowedasthefieldseparator.

Whenpopulatingthefield,thebeginningandendingsentinelsaswellasthe LRCcharacterareremoved.

DataElement36—Track3Data

ThiselementcontainsTrack3dataasread fromthemagneticstripe(seesection2.4.3fordetails).Itisusuallydefinedas ans-104andissupposedtocontaintheTrack3valuewithoutbeginningand endingsentinelsandwithouttheLRCcharacter.However,asboththefieldand theentiremagneticstripetechnologyarephasedout,someimplementationsdo notsupportthefieldanylonger.

DataElement37—RetrievalReferenceNumber Thiselementcontainsanumberthatisusedwithotherkeydataelementstotrackalltransactionsinacardholdertransactionset.Itisusuallydefinedasan-12,however,notalltheimplementationssupportalphabeticcharactersaspartoftheelement.Thevalueis usuallyassignedbytheacquirer,butcanalsobeassignedbythemerchantor electronicterminal.

Toachievethebestinteroperabilitybetweencardschemes,itispreferableto populatethisdataelementwithnumericvaluesonly.

ApossibleandquitepopularwaytogenerateRRNvaluesisaccordingtothe followingformat: YDDDnnxxxxxx

Here, Y denoteslastdigitoftheyear.Positionsmarkedas DDD arepopulated withanumericordinaldate,sometimesalsocalledtheJulianday.Itisanordinal integervalue,assignedtoeachdayoftheyear,startingwith1todenoteJanuary 1.Thevalueiszero-paddedtothelengthofthreeandrepresentsthevalueof dataelement7.Forinstance,avalueof9correspondstoJanuary9thandis representedas009.Thevalueof nn canbesettothehourofthetransactionas

takenfromdataelement7.Finally,thelastsixpositions,denotedas xxxxxx,are setidenticaltodataelement11.

Therefore,atransactionthattookplaceat10amonFebruary13,2012,havingtheSTAN(dataelement11)valueof429132,willisassignedRRNvalueof 204410429132,where2isthelastdigitoftheyear,044istheordinalnumberof February13th,zero-paddedtolengthofthree,thesubsequent10correspondsto thehourandthevalueof429132iscopiedfromtheSTAN.

Dataelement38—AuthorizationCode

Thiselementisdefinedasan-6and containsacodethatisreturnedbytheissuerincasethetransactionisapproved fully,partiallyorunderconditionofIDcheck.Indual-messagesystems,thecode isretainedbytheacquirerandislatersubmittedalongsideclearingrecords,as anadditionalproofoftransactionauthorization.Ifreturnedaspartoftheoriginal authorizationresponse,itisalsosentaspartofthereversalmessage.

Theelementcancontainbetween2to6characters,dependingontheimplementationandaparticularissuer,butcannotbeallspacesorzeros.

Incaseofvoiceauthorization,whenthetransactionauthorizationismadevia aphonecalltotheissuingbank,theissuerprovidesanauthorizationcodeforthe acquirertouseitduringthetransactionpresentment.

Dataelement39—ResponseCode

Thisdataelementisdefinedasan-2inmost implementations,butalsooccursasan-3indialectsbasedonlaterrevisionsof ISO-8583,withtwo-characterresponsecodesthatbyfararemorewidespread.

TheResponseCodeelementdefinestheresultofarequestmessageormessagedisposition.Itispopulatedbytheentitythatprovidestheresponse,i.e., eitherbythepaymentschemesystemorbytheissuer.Itisusedbothinadministrativeandtechnicalmessagesaswellasinfinancialrequestsandadvices.

Atransactionorotherrequestcanbeapprovedinfull,approvedconditionally, approvedpartially,referredtoissuerordeclined.

Fullapprovalisindicatedbyresponsecodeof00.Incaseofpreauthorizationsoraccountvalidationrequests,responsecode85(“Noreasonto decline”)canbealsoreturnedbytheissuerorpaymentthescheme.Bothvalues of00and85canindicatethesuccessoftheoriginalrequest.Thereareadditional approvalcodesincertainimplementations.

Conditionalapprovalisnotsupportedbyalltheschemes,however,certain solutionscanrespondwithcode08—“HonorwithID”.Thisresponsecode,naturallyapplicableinthecard-presentenvironmentonly,instructsthemerchantto checkthecardholderIDandconfirmthatthefullnameonthecorresponding documentisidenticaltothecardholder’snameasseenoncardorextractedand displayedontheterminalbasedontrack1data(seesection3.3.4).

Incaseofapartialapproval,theresponsecodecanassumevaluesof10(“Partialapproval”)or87(“Purchaseamountonly,nocashbackallowed”).Inthese cases,theapprovedamountwillbereturnedindataelement4(“Amount,transaction”),withtheoriginalamountprovidedindataelement54(seesection3.3.4).

Referredauthorizationreceivesaresponsecodeof01or02,whosemeaningis“Refertocardissuer”.Uponreceivingthecode,theshopattendantcan placeaphonecalltotheissuer(bycallingtheacquiringbankthatperformsa subsequentcallorsetsupacallconferencewithanissuerrepresentative,asnecessary)forclarifications.Likeinthecasewithvoiceauthorizations,successful transactionreceivesanauthorizationcodeasaproofoftheauthorization(see alsosection3.3.4).

Besidesprovidingsomeinsightintoreasonsfordeclines,therearereason codeswhichmayormustpromptadditionalactiononbehalfofthecardacceptor. Forinstance,responsecode04(“Capturecard”)instructsanautomatedterminal oranATMnottoreturnthecardtothecardholder,andastoreattendantmayuse thisindicationtoretainthecardincaseitisphysicallysafe.Responsecodes41 (“Lostcard”)and43(“Stolencard”)aresupposedtobehandledinasimilarway, providingadditionaldetailsaboutthereasonforthecardretainment.

Furthermore,certainsolutionshavespecialdeclinecodesforcard-onfile/recurringscenarios,notifyingtheprocessorthatthecurrentandfutureauthorizationshavebeenrevokedandthecarddatashouldberemovedfromthe processordatabase.

Dataelement41—TerminalID Dataelement41isdefinedasans-8andcontainstheidentificatonvalueoftheterminalthatisoperatedbyacardacceptor. Thevalueisusedinconjunctionwithdataelement42(MerchantID)andisutilizedwhenjustthevalueofcardacceptorIDisnotsufficienttouniquelyidentify thephysicalorvirtualterminal.Thevalueisexpectedtobespace-paddedfrom therighttofulllengthofthefield.TheterminalIDisalsosometimesreferredto asTID.Terminalsthatareequippedwithaprinterarerequiredtoprintthevalue onpaperslips.

Dataelement42—MerchantID Dataelement42isdefinedasans-15andcontainstheidentificatonvalueofthemerchant/cardacceptoroperatingtheterminal. ItissometimesreferredtoasMIDorastheCardAcceptorIDandcanrepresent amerchant,aspecificmerchantlocation,orevenanindividualterminal,dependingonthedesignofthespecificmerchant-sidesolution.

Althoughthevaluecancontainalphabeticandevenspecialcharacters,certaincardschemesrelyonitformerchantregistrationforvariousprogramsand therefore,utilizingnumeric-onlyvaluesinthisfieldisusuallythesafestoption.

ThiselementisusedinconjunctionwithDataElement41touniquelyidentify thespecificterminalthatisusedtoprocessthetransaction.

DifferentcardacceptorapplicationsrelyoneithertheterminalIDorthemerchantIDasauniqueidentifierofthecardacceptanceterminalentity,aslong asthecombinationofbothhasaone-to-onecorrespondencetoactualterminals used.

Dataelement43—CardAcceptorName/Location CardAcceptorName/ Locationfieldisdefinedasans-40inISO85831978revision.Itissometimesreferredtoas“BillingDescriptor”andcontainsastringthatiseventuallydisplayed onthecardholderstatement.

Inthecard-presentenvironment,thisfieldmustcontainthemerchant’s“Doingbusinessas”name,cityandcountry,withexactlengthsofeachsubfield slightlyvaryingbetweenimplementations.Inthecard-not-presentenvironment, aphonenumberisoftenpopulatedinthecitypartofthefield,toprovidethe cardholderwiththeabilitytogetintouchwiththemerchantquickly.

Incertaincases,processorsareallowedtosetvaluesinthisfielddynamically.However,schemerulesprescribethatallmessagesshouldstillcarrya well-definedprefixtosimplifytheidentificationbythecardholder.

Dataelement45—Track1Data ThiselementcontainsTrack1dataasread fromthemagneticstripe(seesection2.4.1fordetails).Thisfieldisdefinedas ans-76inmostimplementations.Incertaincases,specialrequirementsareimposedonthefieldseparatorcharacter.Whenpopulatingthisfield,thebeginning andendingsentinelsaswellastheLRCcharacterareremoved.

Dataelement52—PINBlock Thiselementisbinaryandisa64-bitor8-byte binarystring.ItcontainstheencryptedPINblock.Fordetailsontheformatof theunencryptedEPBandthePINencryptionandtranslationprocesses,see13.

Dataelement54—AdditionalAmounts

Theelementhasvariablelengthand canrangefroman-20toan-120in20-symbolincrements.Each20-character valuehasthesamestructure:positions1and2containtheaccounttype(such asdefault,checkingorsavingaccount),positions3and4containamounttype (suchasaccountbalance,previouslyrequestedamountorasurcharge),positions 5through7containcurrencycodeoftheamount,position8containstheamount sign,CforpositiveandDfornegativevalue,andpositions9through20contain theactualamount,withimpliedexponentaccordingtothecurrency.

Thisfieldisutilizedinmultipleusecases.Inmanysolutionsincaseofa partialapprovaltheoriginalrequestedamountisreturnedinthisfield.Inanother popularscenario,theissuermaydecidetoreturntheaccountbalancealongside thetransactionresponseorlistthebalancesonseveralaccounts.Variousissuer surchargescanalsobereturnedasanadditionalamountindataelement54.

Forexample,iftheaccounttypeis“checking”(20),theamounttypeis“availablebalance”(02),thecurrencyisEuro(currencycode978)andthereisapositivebalanceof200euroontheaccount,asingle20-symbolstringisformatted as 2002978C000000020000.

Dataelement55—ICCData ThiselementcontainstheICCdataastransmitted bythecard’sintegratedchipviacontactorcontactlessmeans.Theelementisof

variablelengthandcancontainupto255binarybytesor510nibbles.Whilethe elementitselfisgeneratedduringtheexchangebetweenterminalandcardandis transmittedbythepaymentsolutionsunaltered,itslengthisencodeddifferently indifferentimplementations,beingeitherabinary1-bytevalueora2-byteBCD element.TheelementcontainsBER-TLVdata(seesection11.6).

3.4OtherCardSchemeServices

Besidesroutingofauthorizationandclearingmessagesbetweenthepaymentnetworkparticipants,cardschemesprovidearangeofadditionalservicestomember institutions.

Stand-inProcessing (sometimesabbreviatedasSTIP)activatesinfour-party schemeswhenconnectiontoanissuerisunavailableduetoplannedor unplanneddowntime.Inthiscase,schemesrelyonpredefinedtablesof parameterssetbytheissuerandpre-sharedcardvalidationkeysandpin validationkeystocheckcardintegrity,validatePINcodesandapprove ordeclinetransactions.SophisticatedSTIPsolutionskeeptrackofthetotalcountandamountofauthorizationsaccordingtovariouscriteria.For instance,itmaybepossibletodefineawhite-listedcard,authorizations attemptswhicharealwaysapprovedbySTIP,providedtheyareundera certainthreshold.Oncetheissuercomesbackonline,thedetailsonapprovalsanddeclinesperformedintheirabsencearecommunicatedbythe STIPservice,usuallyinformofadvicemessages.

International,RegionalandNationalSettlement servicescollectanddistributethefundsbetweenissuersandacquirers.Incertainareas(forexample,Iceland)same-daynationalsettlementisperformedasitisalso mandatedbythelocallaw.IncertainregionssuchastheEurozonemost schemessupportnext-daysettlementintheEurocurrency.Finally,internationalsettlementsperformnecessarycurrencyconversionstofacilitate theexchangeoffundsbetweeninstitutions.Schemesdonotsupportall thecurrenciesassettlementcurrencies—forexample,majorschemesperformedsettlementinRussiainsuchcurrenciesaseurosandUSdollarsfor anextensiveperiodoftimewhichresultedinadoublecurrencyconversion foreverydomestictransaction.

FraudPrevention servicesenableonlinetransactionsscoringforfraudprobabilityandtheexchangeofinformationaboutfraudulenttransactionsas wellaslostandstolencardsbetweenthepaymentnetworkparticipants.

DataIntegrity servicesprovideanadditionalvalidationlayeroftransactionformatsanddataconsistencybetweenauthorizationandclearing.Forexample,adataintegrityrulecancheckifatransactionmarkedasae-commerce

inthePOSentrymodefieldarriveswithTrack2data,oranothercontradictionbetweenvarioustransactionparameters.Inthatcase,thetransaction canbeeitherdeclinedonlineoranotificationontheviolationofthedata integrityrulecanbesenttotheparty.

PaymentNetworkTokenization serviceisdescribedinsection4.6.3.

Account-LevelProductManagement

serviceenablesbankstoupdateproductsassociatedwithaparticularcardincaseacardholderhasmetcertain spendingcriteria.Theserviceistypicallyusedtoissueanew,VIPcardto ahigh-spendingindividualwithoutchangingitsPANnumber,sincedifferentcardproductsareissuedindifferentBINranges.Byusinganaccountlevelproductmanagementservice,bankscansparethecardholderthehassleofcommunicatingthenewcardnumbertoallmerchantsthatstoreit onfile.

AccountUpdater

servicesenabletheexchangeofaccountdatabetweeninstitutions.Incasewhenacardisreplacedbyacardhavinganewnumber (forexample,iftheaccount-levelproductmanagementservicewasnot availableorsupportedandthecardholderhadreceivedaVIPcard)oran expiredcardisreissuedwiththesamePANbutanewsequencenumber andexpirydate,thistypeofserviceenablestheissuertocommunicatethe newPANand/orthenewexpirydatetotheacquirer.Theupdateofstored accountsisnormallyinitiatedbytheacquirerthatsubmitsthelistofPANs tothepaymentnetworkservice.Thenthenetworkdistributesinquiriesto supportingissuers,collectsandaggregatestheupdatesandreturnsthem backtotheacquirer.

RecurringPaymentRevocation

serviceenablesissuerstocommunicaterevocationsofrecurringauthorizationstoschemenetworks,thusplacingthe burdenofdecliningthosetransactionsonthenetworkitself.Boththeserviceandtheaccountupdaterservicearedescribedinsection4.6.2.

AddressVerification serviceisdescribedinsection4.5.

CARD-NOTPRESENT ENVIRONMENT

II

4.1Introduction

Inthecard-not-presentenvironment,asthenameimplies,theactualcardordeviceisnotphysicallypresentatwhatisconsideredthepointofsale.Inthis case,themerchantshouldeitherenablecommunicatingthePANandothercard detailsviaachannel(itispredominantlyphone,mailorInternet,althoughin certainimplementationsmobileand“browser-based”channelsaresometimes consideredseparately)orhavethosedetailsavailablefromaprevioustransaction(forinstance,haveacardstoredonfileforbettercustomerexperiencewith thecustomerreturningtopurchaseagain,orhaveasubscription-basedservice withrecurrentbilling).Thespecificsoftheconditionsaredescribedinsection 2.11.

Lackofabilitytoverifythecardholderidentityorthecardauthenticity(at theveryleastbyscrutinizingcarddesignincludinghologramandcheckingthe buyer’sadditionalidentificationdocument),combinedwiththeattractivenessand fastgrowthoftheseremotechannels,hasstimulatedthecreationofseveraltechnicalmeanswhosegoalistoimprovesecurityofsensitivedataandcombatpaymentcardfraudincard-not-presentsolutions.

4.2SecureSocketsLayer

Initially,e-commercetransactionsweresubmittedovertheInternetinplaintext andtherewasnostandardencryptionprotocolcommonlysupportedbybrowsers andwebservers.Carddatawaspronetoeavesdroppingandman-in-the-middle attacks,beingrelativelyeasytocopyorinterceptalongmanyroutingnodesbetweentheclient’sbrowserandtheserver.TheintroductionofSSL(SecureSocketsLayer)byNetscapeCorporationmadetheestablishmentofadirectencrypted tunnelbetweenbrowsersandserverspossible.

TheSSLprotocollatersupersededbyTLS(TransportLayerSecurity)containsthreeprincipalsecurityfeatures.First,duringtheestablishmentofthetunnel,theserver-sidesignedcertificateiscryptographicallyvalidatedbytheclient (thebrowser).Thenarandomsecretsymmetricencryptionkeyisgeneratedand sharedbetweentheclientandtheserver.Second,thecommunicationsbetween theclientandtheserverareencryptedusingthatone-timekey.Finally,each messageexchangedoverthetunnelcontainsadigitalsignature.

4.33DSecure

Thedevelopmentanddisseminationofstandardizedinteroperablemeanstoestablishsecurecommunicationchannelsbetweenbrowsersandcardacceptor serversresolvedtheproblemofeavesdroppingtochannelsthattransfersensitive

paymentdata.However,thatdidnotallowanyauthenticationofthecardholder orthecardbeyondCVV2(seesection2.5.3).Toaddresstheproblem,schemes haveexperimentedwithvarioustechnologiessuchasSET(SecureElectronic Transactionprotocol).Thoseattempts,however,provedtobeunsuccessfuluntill anon-invasivetransparentandbrowserbased3DSecuremethodemergedand gainedtraction.

ThatXML-basedprotocolwasoriginallydevelopedbyArcotSystemsunder thenameofTransFortanditsusewasannouncedbyVisaUSAin2001.Itwas originallydeployedunderthenameof“VerifiedByVisa”.Later,itwasadopted byothermajorindustryplayers,suchasMasterCard(underthenameofMasterCardSecureCode),JCB(asJ/Secure)andAmericanExpress(asAmerican ExpressSafeKey).AswasthecasewithISO8583financialtransactionmessagesstandard,theprotocolallowsforcertainflexibilityinimplementationand hencetheactualsolutionsslightlyvarybetweencardschemes.

Theprotocoliscalled“3Dsecure”where“D”standsfor“domain”anddenotesathree-domainmodel,withthedomainsdefinedastheacquirerdomain, theissuerdomainandtheinteroperabilitydomain.Inanutshell,duringa3D Securetransactionthecardholder,whileshoppingonane-commercewebsite isredirectedtoanadditionalauthenticationpagehostedbytheissuingbank. Thepageperformsanadditionalauthenticationusingeitherpre-sharedstaticor aone-timedynamicpassword.Thentheissuersystemgeneratescryptographic evidenceoftheauthenticationlaterforwardedbytheacquireraspartoftheauthorizationrequestforthetransaction.Earlierimplementationsoftheprotocol supportedtheActivationDuringShopping(ADS)featureaswell.Thefeature allowsthecardholderforwhomtheauthenticationisattemptedforthefirsttime toberedirectedtotheirissuer’swebpagetoenrollfortheservice.Theenrollment istransparenttothemerchant:uponitscompletion,themerchantseescontinuationoftheshoppingprocessbythecardholderasifjusttheauthenticationof thetransactionwasperformed.Thatfeatureledtocriticismoftheprotocolby securityexperts,sincetheintegrationof3DSecureintomerchantflowwhich wasIFRAME-basedallowedforeasyspoofingoftheissuer’swebsite,whichin thiscasewouldbehardtoidentifyevenbyasecurity-savvycardholder.

4.3.1Overview

Figure4.1 containsmajorfunctionalmodulesofa3Dsecuresolution.Ithas beenpurposelysimplifiedtodisplaycomponentsonlyrelevantforacquiringof payments.

MPI(MerchantPlug-In) isintegratedintomerchantonlinestores.Ithandles communicationswiththepaymentschemesandtheissuers.Itisresponsibleforcheckingtheenrollmentstatusandthenprocessingcardauthentication.

Figure4.1:Majormodulesof3DSecuredomains

DirectoryServer authenticatesthemerchantandisqueriedfortheenrollment statusoftheissuerandthespecificcardbytheMPIwhilealsoservingas aroutingentityforrequeststoACSortheStand-Inservice.

ACS(AccessControlServer) servicesrequestsforauthenticationontheissuer side.Itcheckstheenrollment,performsauthenticationandgeneratesthe cryptographicevidenceoftransactionauthentication.Itcanalsoperform serviceactivationduringshopping,i.e.,allowthecardholdertosignupfor 3DSecureduringthepurchaseprocess.

Attempts/Stand-InService generatescryptographicevidenceofanauthenticationattemptmadebythemerchantincaseswhentheissuerdoesnotsupporttheservice,thespecificcardisnotenrolledorwhentheissuerACS isunavailable.

The3DSecureauthenticationprocessconsistsoftwosteps:participationcheck andpayerauthentication.

4.3.2ParticipationCheck

Aspartofthestep,theissuerandthecardparticipationin3DSecureserviceare checked.Duringtheparticipationcheck,themerchantalsogetsauthenticated whenacertificatethatisdeployedaspartofMPIisvalidatedbythedirectory server.

TheprocessbeginswithMPIissuingarequesttotheDirectoryServer.If theauthenticationofthemerchantissuccessful,theDirectoryServerdetermines theaddressofanappropriateACS,basedonPANdataprovidedbytheMPI andforwardstherequesttoit.IfnoACSisavailableorthecardholderdoesnot participatein3DSecureservice,theDirectoryServerroutestherequesttothe Attemptsserviceinstead.

TheresponsefollowstheroutefromACSortheAttemptsservicetotheDirectoryServerandbacktotheMPI.Ifaspartoftheroutingthecorresponding systemhasindicatedthatnoauthenticationornoattemptedauthenticationresponseisavailable,theflowterminateswithMPIindicatingthestatustothe invokingapplication.Otherwise,PayerAuthenticationcommences.

4.3.3PayerAuthentication

DuringPayerAuthenticationtheMPIredirectsthecardholder’sbrowser(usually inanembeddedIFRAME)totheissuerACS.

TheACSperformsauthenticationstepsaccordingtotheimplementationdecideduponbytheissuer.Ifthecardholderalreadyparticipatesinthe3DSecure service,theissuerconfirmsthecardholder’sidentityusingaone-timepassword textedtothecardholder’smobilephone,apushnotificationtotheissuer’smobile apporapre-sharedstaticpassword.Ifthecardholderhasnotsignedupforthe service,theissuerhastheoptiontoperformActivationDuringShopping.

Duetoahighdrop-outrateoffull3DSecuretransactions,manyissuerselect toincreasinglyrelyonrisk-basedauthentication,skippingtheauthenticationaltogetherincasethetransactionissafeaccordingtotheirownriskevaluation rules.

Theissuercanprovideanattemptedauthenticationresponsewhenforsome reasontheauthenticationisnotavailablefortheparticularcardholder.

Asmentionedabove,incaseswheneithertheissuerorthecardholderis notenrolledtotheservice,theAttempts/Stand-Inserviceprovidesanattempted authenticationresponse.TheredirectiontotheserviceishandledbyDirectory ServiceandistransparenttotheMPI.

TheACSortheAttempts/Stand-Inserviceresponsecontainsauniquetransactionid,theindicationoftheauthenticationresult(failed,attempted,succeeded) andcryptographicevidenceoftheauthenticationorattemptedauthentication. ThatresponseisforwardedbacktotheMerchantPlug-InbytheDirectoryServer forfurtheruseintheauthorizationrequest.

4.3.4PayerAuthentication

TheACSortheAttempts/Stand-Inserviceoutputsshouldbeincludedinthe authorizationmessagethecardacquirersendstothepaymentnetworkafterthe 3DSecureflowcompletion.Boththedataelementandtheencodingofthevalues varybetweenschemeimplementations.

Thebinaryevidencecanbesentasabinaryvalue,asahexstring(i.e.,as astringofASCIIcharacters0-9andA-Frepresentingthenumericvalues)or inBase-64encoding(seesection11.5),ineitherASCIIorEBCDICcharacter encoding.

TheevidenceissometimesreferredtoasUniversalCardholderAuthenticationField(UCAF)orCardholderAuthenticationVerificationValue(CAVV).

ThetransactionIDisnotmandatoryinallcasesandalsovariesinrepresentation.

The3DSecureauthenticationattemptstatusisreferredtoas“ECI”or“ECommerceIndicator”andistypicallyrepresentedasatwo-orthree-digitcode indicating“fullauthentication”,“attemptedauthentication”and“noauthentication”andhavingvaluesof05,06,and07,correspondingly.

4.3.53DSecureAdoptionandChallenges

Visa,aswellasothercardschemes,wereinterestedinpromotingtheuseof3D Secureprotocolinthee-commerceenvironment.Forthatpurpose,schemesintroducedlowerinterchangerates,benefittingmerchantcosts,andalsoannounced achargebackliabilityshiftforcertainchargebackreasoncodes.

However,cardholdersdidnotrespondwelltotheintroductionofthe3DSecureauthentication.Abandonmentratesofshoppingcartsduringonlineshoppingwereindoubledigitsor,bysomeestimates,ashighas40%.Itappeared thatmanycardholderseitherdidnotrememberordidnotrenewtheirpre-shared password.

Thesituationwasslightlyalleviatedbyissuersswitchingtorisk-basedauthentication,duringwhichtheissuerACSestimatesfraudulenttransactionrisks andincaseoflowriskprovidesthenecessarycryptograminamannertransparenttotheenduser.

ThatcardholderauthenticationmethodbecamewidespreadintheUnited Kingdomdramaticallyloweringthedrop-outrates.

However,theemergenceofsuchmultipleInternet-connecteddevicesas tabletsandsmartphonesalongsidewithanincreasedsensitivityofmerchants tocustomerexperiencemadethe3DSecureprotocolsomewhatoutdated.Itdid requirethedisplayofanissuer-generatedwebpage(framedorfull),arequirementwhichcomplicatedthedevelopmentofmobileapplicationsandforcedweb e-commercestorestodisplayapaymentstepthatstoodinstarkcontrastwiththe restoftheiruserinterfaces.

4.43DSecure2.0(EMV3DSecure)

Toaddressthe3DSecurechallenges,in2014,VisaandMasterCarddeveloped andcontributedtoEMVCo,adraftof3DS2.0specification.Thespecification waspublishedasastandardin2016,and,unliketheproprietary3DSecure,the newversionoftheprotocolisprovidedtotheindustryroyalty-free.

Bydesignthenew3DSecure2.0protocolpromotestheissuer-siderisk-based authenticationaimingtoidentifylegitimatetransactionscorrectlyandmakethem asfrictionlessaspossible.

4.4.1MajorChangesin3DSecure2.0

Thenewprotocoldiffersfromitspredecessorinalmosteveryaspect.

Tobeginwith,itisnolongerXML-basedbutreliesonJSONastheformat forallitsmessages.ItalsoutilizesJWE(JSONWebEncryptionaccordingto RFC7516).

Thenewprotocolsupportsfrictionlessflowbydesign,allowinginvolvedpartiestoavoidtheadditionalredirectiontotheissuerACSaswellasenablingthe transmissionofadditionaluserdatatotheissuer,thussimplifyingthetaskof makingariskassessment.

AsfortheUI,theprotocolcontinuestosupportbrowser-basedredirectionto ACS,butalsointroducesnativeandHTMLUItemplatesformobileapplications, allowingseamlesscustomerexperiencesontheseparties.

Inadditiontointeractiveexchangesof(possiblyseveral)challengesandresponsesbetweenthecardholderandtheissuer’ssystemstheprotocolallowsperformingdecoupled/out-of-bandauthentications,whereasthecardholderswitches totheissuer’sapptoconfirmthetransaction.

Anotherflawpresentin3DSecure1.0waswith“disappearing”userswhen afterredirectiontoanACS,themerchantstorefrontcouldonlylearnaboutthe outcomeoftheauthenticationifitseverystepworkedproperlyandtheuserwas redirectedbacktothemerchant’swebsite.In3DSecure2.0theloopisclosed withaspecialnewmessagesentbackfromtheissuertotheacquirer.

Finally,theprotocolintroducedthesupportfornon-paymentauthentication andmerchant-initiatedrequests.

Inadditiontotheprotocol,thestandardincludesadefinitionofSDKforuse onmobiledevices.

4.4.23DSecure2.0ActorsandMessages

Thenewstandardintroducedslightmodificationstotheterminology.MPIisnow replacedwith 3DSServer,merchantstorefrontisreferredtoas 3DSRequestor, whileamobileappontheconsumerdeviceis 3DSClient.Directoryserverand ACSretainedtheirnamesfromthepreviousversionoftheprotocol.

Asmentionedpreviously,allmessagesareJSONobjects.Amessagetypeis definedbythe messageType field.

Any3DS-relatedflowisprecededbyoneorseveral PReq messagessent bythe3DSServertoDirectoryServersitknows.EachDSrespondswitha PRes message,providingthecardnumberrangesandsupportedprotocols,thus enablingthe3DSServertoroutefutureauthenticationrequestsproperly(see figure4.2).

Figure4.2:PReqandPResmessages

Theauthenticationbeginswithan AReq message.Itcontainstransactiondetails,ifusedforpaymentauthentication,bothbasic(onparwithdatasentin 3DSecure1.0messages)andextended.IncaseofmobileSDK,italsocontains cryptographicaldatausedforkeyexchange.Thehigh-levelflowisshownin figure4.3.

Themessageissenteitherbythemerchant’sapporstorefronttothe3D ServerroutingittotheappropriateDirectoryServer.Thelattermayeitherrespondtoit(scenario1in figure4.3)orforwardittoanACS.

In ARes,theresponseto AReq,theACSortheDirectoryServerprovidesauthenticationstatusaswellascorrespondingadditionaldetails.Anauthentication requestcanbeapprovedbyACS(scenario2)oranevidenceofauthenticationattemptcanbegeneratedbyDS(scenario1).Inthesecases,the ARes willcontain necessaryauthenticationdata.TheACSmaydecidethatachallengeisrequired. Inthatcase,the ARes messagecontainsanACSURL(scenario2in figure4.3). Finally,theauthenticationrequestcanberejectedrightawayandthestatusvalue arrivesaspartofan ARes message,too.

Whenasaresultof AReq/ARes messageexchangetheACSinformedthe merchant-sidesystemthatachallengeisrequired,itoccursviaadirectinteractionbetweenthe3DRequestorandtheACS.Inthecaseofabrowser-basedflow theinteractionoccursviabrowserredirectionandusingHTTPPOSTrequests. InthecaseofanSDKormobileappingeneraltheapplicationsendsoneor several CReq messagestotheACSreceivingin CRes informationregardingthe interactionstatusaswellasnecessarydetailsforasubsequentstepinit(e.g.,first CRes cancontainUItemplatedetails,whileasecondonecarriesaconfirmation ofsuccessfulcardholderauthentication).

Priortoissuingafinal CRes tothe3DRequestorenvironment(intheform ofaresponseto CReq orbyredirectingthecardholder’sbrowserbacktothe

Figure4.3:AReqandAResmessages

merchantstore)theACSsendsa RReq messagebackto3DServerviatheDS, notifyingitoftheauthenticationattemptoutcome.TheACSwaitsforanacknowledging RRes messagebeforesendingthefinal CRes tothe3DSRequestor.

Eachtransactionperformedinthe3DS2.0environmentgetsuptothreeidentifiers:3DSServerID,DirectoryServerIDandAccessControlServerID,ifthe transactionreachesDSandACS,accordingly.

Itisworthnotingthatthe authenticationValue fieldcontainingthecryptographicevidenceofthecompletedauthenticationcanbepresenteitherin ARes orin RReq messagesbutneverinCRes.

4.4.3Browser-basedFlow

Duringinitializationthe3DSServerobtainsBINrangesfromseveralDirectory Servers.Someoftherangesmayincludetheso-called3DSMethodinformation. The3DSMethodisanaddresstowhichthemerchant’sstoremustperforman HTTPPOSTrequestwith3DSServertransactionIDpriortoattemptingauthentication.ThepurposeofthisstepistoallowtheACSoranotherlinkedsystemto gatherwhateverdeviceandbrowserinformationitcandiscernfromtheHTTP request.

Aftercompletingthatoptionalpreparationstep,the3DSServercraftsan AReq messagethatissenttoDSand,throughit,totheACS.

IftheACSdoesn’tsupport3DS2.0andan“attempts”serviceissupported bytheDS,itcraftsan ARes withcorrespondingauthenticationvalueandsends ittothe3DSServer.

IncasetheACSdecidestoauthenticatethecardholderinafrictionlessmanner,itreportssointhe ARes.Otherwise,theACScanrequesteitheraChallenge oraDecoupledauthentication.TheChallengeflowisshownin figure4.4

Figure4.4:Browser-basedauthentication—Challengeflow

IftheACShasrequestedachallenge,the3DSServercraftsa CReq message, encodesitusingBase64encoding(seesection11.5)andplacesitinaformwhich thebrowserwillthenautomaticallyposttoanACSURL.The3DSRequestor environmentawaitsa RReq messagefollowedbyanotherHTTPPOSTrequest

bythecardholder’sbrowser,inwhichthe CRes messageisincludedinasimilar manner.

ThecardholderisredirectedtotheACSenvironmentwhereanynecessary authenticationstepsareperformed.Uponcompletionoftheeithersuccessfulor failedchallenge-basedauthenticationtheACSsendsan RReq messagetothe 3DSServerviaDS.

Incaseofadecoupleauthentication,therearenofurtherUIinteractionswith thecardholderaspartofthe3DS2.0flow.The3DSServerhastowaitforan RReq fromtheACS,containingnecessarydetailsregardingthedecoupledauthenticationoutcome.

4.4.4App-basedFlow

Theapp-basedflowbeginswhentheapplicationissuesan AReq tothe3DS Server.ThelatterforwardsittoanACSviaaDS.Incaseofafrictionlessauthentication,the ARes containtherequiredauthenticationvalueandtheflowends.

Otherwise,ifachallengeisrequired,theappcraftsa CReq andsendsitdirectlytotheACS.The CReq containsanindicationofsupportedUIoptions, includingnativeUI,HTMLorboth.

Thefirst CRes fromtheACScontaintheappropriateUIdefinitions:either anHTMLthatisrenderedas-isoradefinitionofnativeUIcontrolsthatthe applicationhastorenderonthemobiledevicescreen.

Atthisjunction,theflowcancontinueineitherChallengeorOut-of-band modes.

InChallengemodetheapplicationcapturesuserinputandsubmitsittothe ACSviaa CReq message.Innativemode,thevaluesofUIcontrolsrenderedby theapplicationareused.InHTMLmode,theapplicationinterceptstheGETor POSTrequestthatoriginatesfromtheHTMLformembeddedintotheUIand sendsthevalueina CReq request.

Theinteractioncontinuesuntilan RReq arrivesatthe3DSServerfollowed byafinal CRes senttotheapplicationbytheACS.Theinteractionisshownin figure4.5

Incaseofout-of-bandflowthecardholderfollowsapushnotificationorwritteninstructionstoswitchtoanother(issuer-provided)app.Accordingtothestandard,theSDKsendsanother CReq requestautomaticallyanytimetheoriginating merchantapplicationreturnstotheforegroundofthedevice.TheACSperforms cardholderauthenticationinaseparateflowandupdatesthe3DSServerwith a RReq uponitssuccessfulcompletion.Themobileapp,inturn,learnsofthe authenticationsuccessonceoneof CReqsitre-sendsreturnswithauthentication results.

4.4.5Merchant-initiatedTransaction(3RI)

Incaseofa3RI(3DSRequestor-Initiated)flow,thereisnocardholderUItobe displayed.Therearethereforethreepossibleoutcomesofsucharequest:either thetransactionisauthenticated,thusprovidinganadditionalconfirmationof, forexample,validityofarecurringsubscription,orthetransactionisrejected, notifyingthemerchantthattheirstandingorderauthorizationisnolongervalid, or,finally,adecoupledauthenticationlaunches,verifyingcardholder’sidentity andconfirmingthetransactionviaaseparatechannel.

Incaseof3RI,the3DSServerissuesan AReq request.Iftherequestresults areinadefinitiveanswer,itisprovidedbackfromtheACSinan ARes.Otherwise,ifadecoupledauthenticationislaunched,the3DSServerlaterreceivesan RReq messagecontainingtheresultofthedecoupledflow.

4.4.6EMV3-DSecureSecurity

Theconnectivityof3DSServerstoDSandbetweenDSandACSissecured usingTLScertificates,aswasthecasewith3DSecure1.0.Communicationbetweenmerchantsystemsandthe3DSServerisalsoperformedoverasecure sockettunnel.

However,incaseof3DSSDK,additionalmeasurestoprotectthedataare undertaken.

Thedeviceinformation3DSSDKsendsalongside3DSmessagesisencryptedwithapublickeyofthecorrespondingdirectoryserver.Theencrypted dataislatersenttothe3DSServerin“SDKEncryptedData”dataelementaspart ofan AReq message.Thedistributionofsaidkeysisnotcoveredinthestandard, butitisassumedthatthe3DSServeriscapableofprovidingapublickeyforthe apptouse.

TosetupofcommunicationbetweenACSandtheapplicationakeyexchange mechanismcalled“EllipticCurveDiffie-Hellman”isutilized.UsingthemechanismtheSDKsendsaSDKEphemeralPublicKeytotheACSinthe AReq message.TheACSrespondstoitinthe ARes withanACSEphemeralPublic KeyadditionallysignedwithacertificateoftheDSalsoknowntotheSDK. Eachside,theSDKandtheACS,canusethepairofephemeralpublickeys toconstructamutuallysharedsecretkeytoencryptallsubsequent CReq/CRes messageexchanges.

4.5AddressVerificationService(AVS)

TheAddressVerificationServiceisanotherserviceprovidedbyschemesthat aimstodecreasefraudbyincreasingthenumberofindependentdetailsthatcan bevalidatedduringacard-not-presenttransaction.

Theserviceallowsthevalidationofsomeorallofthecardholderpersonal details,suchasthecardholder’sname,billingstreetaddressandbillingzipcode, versusdataonfileattheissuerbank.

Duringthecheckoutprocessthecardacceptor,inadditiontoPAN,captures theexpirydateandCVV2,thecardholder’snameandbillingaddress(i.e.,the addresstowhichcardstatementsaresentbytheissuerbank).Theseadditional fieldscanbesenttoschemeseitherseparatelyfromtheauthorizationrequestor aspartofit,receivingaresponseonaddressverificationresults.

Afailedcardholder’snameorbillingaddressverificationdoesnotautomaticallyresultinanauthorizationdeclinebutcombinedwithothersuspiciousindicatorscandrivethemerchant’sdecisiontodeclineorcancelthetransactionat thefront-end.

ThecardacceptorortheacquirerbankcanlaterusetheAVSresulttomakea decisiononeithermovingthetransactionforwardorcancelingit(bynotautho-

rizingorreversingtheauthorization).Forinstance,anadvancedfraud-prevention systemcantakeintoaccountdiscrepanciesbetweenshippingaddress,billing address,cardcountryasidentifiedbyitsBINandgeo-locationdatabasedon customerIPaddressanddecidethattheoverallriskscoreoftheparticulartransactionistoohigh.

Addingmorefieldstobemanuallypopulatedbyacustomerincreasesapossibilityofgettingafalsenegativeresponseforavalidtransaction.Toavoidissues relatedtohumanmistakesordifferencesinspellingAVSvalidationisperformed usingtheso-calledcondensedformat.Inmostimplementationstheserviceextractsnumericsymbolsfromtheprovidedstreetaddress,inorderofappearance andcomparesthemtothedatastoredonfileforthecardholderratherthancomparingthefullstreetaddresstotheonestoredintheissuersystems

Asanexampleconsideracardholderwhoseaddressis“1600Pennsylvania AveNW”.Whileregisteringtheaddressintheissuersystem,itistobestored bothinfullandcondensedformatas“1600PennsylvaniaAveNW”and“1600”. Duringtheverificationthecustomercanspelltheaddressas“1600Pennsylvania Av.”or“1600PennsylvaniaAve”butasthenumericalpartsmatchthefieldpasses verification.

Arequesttovalidatetheaddressisusuallybundledwiththeauthorizationrequestandtheresultoftheaddressverificationarrivesinaproprietaryfieldvaryingpersolutionbutingeneral,reflectsthestreetaddressstatusandzipcode.Each ofthosecanroughlyhavethefollowingconditions:“providedandmatched”, “provided,notmatched”,“provided,notvalidated”and“notprovided”.Dependingonthespecificimplementation,certaincombinationsoftheconditionscan becoalescedintoone.Furthermore,insomecasesthereareseparateindicators fordomesticandinternationaladdressvalidationresults.

MostAVSimplementationslimitthevalidationtothestreetaddressincondensedformatandzipcode.TheserviceiswidespreadintheUnitedStates,the UKandCanadawithlesstractionelsewhereintheworld.

4.6Tokenization

Atokeninthepaymentindustryisasurrogatevalueusedinsteadofanactual PANtoperformpaymenttransactions.Originallyusedinthecard-not-present environment,tokenizationuseshavebeenextendedtothecard-presentenvironmentwithcontactlesstechnology.Astokensareveryapplication-specificandin manycasesareboundtoasinglecardacceptor,relyingontokenizedPANvalues reducesfraudriskthatfollowsfromdatatheft,andatokenobtainedfromone merchantisnotusablewithothermerchants.

Thecarddatacanbetokenizedoneitheracquirer/processorsideorinthe paymentnetwork.Theformeriswidespread;thelatterisemergingbutgained

significanttractionwithtechnologieslikeApplePayTM orSamsungPayTM based ontheEMVTokenizationstandard.

Thecoredifferencebetweentwoapproachestotokenizationisshownin figure4.6.

Figure4.6:Processorandpaymentnetworktokenization

4.6.1ProcessorTokenization

Considerthebusinessscenarioofsuchasubscription-basedserviceasutilities oramagazinesubscriptionwithmonthlybilling.Everymonthatacertaindate (afterclosureofabillingcycleincaseofutilitybills),thecardholderneedsto bechargedaparticularamounttothecardstoredwiththeprocessoronbehalfof theserviceprovider.Todothattheprocessor’ssystemshouldforwardaproperly formedauthorizationorclearingrequesttotheschemewhich,inevitably,hasto containafullPAN.

ThatmeansthatthePANmustbestoredforthedurationofsubscription, potentiallyuntilitsexpiryalongsideitsexpirydate.Besides,suchadditionalauthenticationandfraudpreventionmeansasCVV2validation,theaddressverificationand3DSecureareavailablewiththefirsttransactionintheseriesor uponsubscriptionsetup,butthevaluesarenotstoredforsubsequenttransactions.AsCVV2valueisusedtoconfirmthecardvalidity,oncestored,itdoes notmakesubsequenttransactionsanymorevalidbutincreasesariskoftheft;

addressdatamaychangeduringthelifetimeofasubscriptioncausingfalsenegativeresponses,andthe3DSecureprocessgeneratescryptographicevidenceof cardholderidentityatthetimeofthetransactionwhichisnotvalidforreuse.

Inasolutionwhichstoressuchsensitivedataaspaymentcarddetails,data inthestorageitself(i.e.,databasefilesonadiskarray)isvulnerablefordata theft.Hence,asolutionthatbecamewidespreadintheindustrywasnottostore thepaymentdatainclear-textbuttoencryptitwhileitisstoredandonlyhandle clear-textdatainmemoryforasashortperiodoftimeaspossible.

Thiscanbeachieved,forinstance,byutilizinganHSM.Forthepurposeof describingthedataflowletusassumethattheLMKistheactiveHSMmaster keyandthatDEKdenotes“dataencryptionkey”,ageneric-purposekeythatis generatedbytheHSMandwhoseclear-textformisneverexposed.

ThetokenizationsolutionstoresasingleDEKLMK (aDEKencryptedby LMK)butcertainlyafullsolutiondeploysmultipleDEKsatleastforkeyrotationpurposes.

Considerabusinessscenariowhenaconsumersignsupforautomaticpaymentofautilitybill.Therearetwopossibleoptionshere:eitherthecardholder signsupforafuturepaymentorthecardholderpaysoneofthebillsimmediately. IneithercasethecardacceptorcapturesthePANandcardexpirydateandgathersdataforadditionalcardholderandcardvaliditychecks:thecardholderalso providesCVV2,entersabillingaddressforanAVScheckand,forthesakeof theexample,performsa3DSecureauthentication.

Tobetterillustratetheprinciples,assumethatconsumerdataandthebilling processesareperformedinamerchant-ownedbillingsystem,externaltothecard paymentprocessor,anentityresponsibleforhandlingthepaymentsitself.

PriortothetokencreationtheprocessorperformseitheraPurchasetransactionoranAccountvalidationtransaction,dependingonwhetherthereisa paymenthappeningsimultaneouslywithstoringthecardonfileornot,correspondingly.TheprocessorsendsthePAN,expirydate,CVV,billingaddressand 3DSecureauthenticationdatatothepaymentschemeanduponthesuccessful completionoftheoperationperformsthefollowingsteps:

Atalaterstageupontheclosureofautilitybillingcycle,themerchant-owned billingsystemdecidestobillacertaincard.Thebillingsystemextractsthevalue ofTandsendsittotheprocessoralongsidenecessaryadditionaltransactiondetails(amountetc).Uponreceivingthisrequest,theprocessorperformsthefollowingsteps:

1.ThevalueofTisusedtoretrieveVDEK fromthedatabase.

2.VDEK andDEKLMK withtheLMKaresenttoHSMfordecryption.

3.TheHSMdecryptsDEKLMK withtheLMKthatisstoredinternally,then usesclear-textDEKvaluetodecryptVDEK.

4.Theclear-textvalueofVisreturnedtothecallersystem.

5.TheprocessorsystemdoesnotstoretheVvaluebutextractsthePANand expirydatedatafromitandtransmitsittothepaymentschemedirectly.

Anautomaticbillingsystemactingatthebackendandhavingnointeraction withthecustomeratthepointofpaymentcannotobtainandthereforeprovidea CVVvalue.With3DSecure1.0,noauthenticationwasalsopossible.With3DS 2.0,itispossibletoinitiatea3RIflow(seesection4.4.5),duringwhich,either theACSwillapprovethetransactionoritwillreachouttothecardholderfora decoupledauthentication.However,inthescenarioofrecurringutilitybillsthis scenarioisunlikely.

Therefore,suchatransaction(asubsequentrecurringtransaction)istransmittedwiththePANandexpirydateonly.However,theoriginalaccountvalidation orpurchasedidcontainconfirmationofthecardvalidityandcardholderidentity,hencetheissuercanstillensurethevalidityoftherequest,providedthat thistransactionisproperlymatchedtothefirsttransactioninseries.Inmostcard schemesolutions,inordertosimplifythetasktransactionsaremarkedasrecurringwithaproprietaryflagorvalue.

Thatdiffersfromthecard-on-filescenario.Toillustrateitconsiderthefollowingexample:amerchant,anonlinee-commercestore,offersitscustomersto savetheirpaymentcardforfutureeaseofpayment.This,too,canbedoneindependentlyorjointlywithapurchase.Inthescenariothetokenizationhappens inexactlythesamemanner:thecardholderandthecardareauthenticatedwith availableandsupportedmeans,andthecardnumberandcardexpirydatearesecurelyencryptedandstoredintheprocessorsystem.However,subsequentre-use ofstoredvaluesisinteractiveandhappenswithasubsequentpurchase:themerchantcanpromptthecardholderforsuchadditionalauthenticationasreentryof theCVVvalueorachallenge-based3DSecureauthentication.Thenthedatacan besenttocardschemesalongsidethePANthatwasstoredonfile.Thisoption improvessecuritybutslightlyimpairsusability,hencemanymerchantsolutions

donotsupportit.Todistinguishanautomatedrecurringtransactionfromacardon-filetransactioncertaincardschemeprotocolssupportaproprietaryflag(see alsoStandingAuthorisationinsection2.11).

4.6.2RevocationofAuthorizationandAccountUpdater Services

Acardholderwhoprovidescarddetailstoamerchantoraservicescompanyis chargedrecurringlyuntilthecontracthasterminated.However,whenacardisno longervalid(forinstance,ithasexpiredorwasstolenandhadtobeblockedand replacedbytheissuer),allfuturerecurringtransactionsaregoingtobedeclined.

Toreducethenumberofunsuccessfulauthorizationattemptssomeschemes providespecialdeclinecodesallowingissuerstodistinguishgenericdeclines fromthosefollowingfromoneofthespecificuse-casesmentionedabove.They areoftencalled“revocationofauthorization”anduponreceivingsuchacode,the entitystoringthetokenizedaccountdetailsonfileshouldceasetheirrecurring PANauthorizationattempts.Insomecasesschemesfurtherunburdenissuersby allowingthemtodefinePANslistsforwhichtherecurringauthorizationsare declinedbyschemenetworkswithoutreachingtheissuer.

ThemechanismonlyprovidestheindicationofarevokedPANauthorization duringanauthorizationattempt.However,acardcanberenewed(issuedwith anewcardsequencenumberandnewexpirydate)oranewcardcanbeissued forthatcardholder(andinthiscasethecardholderusesanewPAN).Asimple responsecodecannotcarrythedetailsandforsuchcasesschemeshavedeployed “accountupdater”services.

Atypical“accountupdater”serviceisafile-basedcardschemeservicereceivingaPANslistandexpirydatesfrommerchantseitherdirectlyorviatheir acquirers.Thentheservicedistributesinquiriestoissuers,gathersbacktheresultsandrespondswithafilethat,inanutshell,containsabriefstatusofeach submittedaccount.Anaccountcanbevalidandhaveanewexpirydate,oranew PANvalueandexpirydate,andcorrespondingvaluesareavailableinthescheme response.

Uponreceivingaresponsefile,theprocessororotherentitykeepingthePANs onfileshouldupdateexpirydatesandPANnumbersasinstructed.Theimplementationoftheserviceproactivelyinformstheprocessoroflegitimatechanges onthecardholderaccount,helpingavoid“Donothonor”and“Revokeauthorization”declinesuponfutureauthorizationattempts.

4.6.3PaymentNetworkTokenization(EMVTokenization)

Carddatatokenizationontheprocessorsidehasseveraldisadvantages.

Specialprovisionsmustbemadetosecurethedataontheprocessorside properly.However,evenwithallthenecessarycompliancemeasuresinplace,

abundanceofrecurringbillingsetupsbycompaniesandonlinestorescapableof card-on-fileshoppingmeansthatthecardholder’sPANisdistributedacrossmultipledifferentsystemsbeyondthecardholder’sandcardholder’sbankcontrol.

Inordertoprovidethestoredcarddataalwaysbeuptodate,issuers,schemes andprocessorsmustallimplementaccountupdateservices(seesection4.6.2) whicharenotubiquitous.

Eventhoughmanypaymentplatformsarebuiltwithprocessortokenization supportinmind,thevarietyoftokenformatsmeansthatsystemshavetobe adoptedtoeitherpassthroughtokenvaluesoratleastcarryanindicatordistinguishingaone-timetransactionfromatokenizedone.Also,therearenoprovisionsforstandardizedprocessortokenformatsinthepaymentindustry.

Toaddressthechallenges,returncontrolofcarddatatoissuersandcardholdersandenablesuchnewpaymentmethodsasApplePay,schemesandtheEMV consortiumhaveintroducedpaymentnetworktokenization—amethodwhenthe tokencomplieswiththestandardPANformatbutistranslatedtotheactualPAN numberbythenetwork.

TheEMVconsortiumstandardgoverningpaymentnetworktokenizationis plainlycalled“EMVPaymentTokenizationSpecification”,whichissomewhat counterintuitivesincethebulkofEMVco-standardsgovernpurelycard-present transactions.

Atthefirstglance,themethoddoesnotmakealotofsenseasaPANis acardholder-providednumber(all-digits,13to19positionsinlength)thatis securelystoredonfilebyaprocessorandsentas-istothepaymentnetwork, butsoisanetworktoken.However,unlikethe“general-purpose”PANnumber embossedonthecard,writtenonthemagneticstripe,storedintheICCandused astheprimarykeyforthecustomeraccount,thetokenmightbeshort-livedand limitedtoaparticularchannelandpaymentmethod.

Tosupportpaymentnetworktokenization,schemeshaveintroduceddedicatedBINrangesreservedfortokenizedPANs(atthemomentofwritingtokenizedPANvaluesareassignedthe“2”IIN).AsBINtablesareupdatedfrequentlyallplayersinthecardpaymentsindustryfacelittlechallengeswithintroducingthenewfeaturepassivesupport,simplyenablingthePANspass-through fromthenewrangethroughtheirsystemsandintopaymentnetworks.

4.6.4PaymentNetworkTokenizationinMobilePayments

Asmentionedabove,anetworktokencanbetiedtoaparticulardeviceanda particulardataentrymode.Considerthefollowingscenario:

Themanufacturerofthemobiledeviceorthepaymentapplicationor frameworkproviderregistertheownerofthedevicetoacloud-based paymentservice.Thedeviceownerisauthenticatedusingsuchmeansas

thedevicePINcode,astaticoraone-timepasswordorusingabiometric method.

Theownerofthedeviceregisterstheirpaymentcardorcardstothepaymentservice.Theprocesscanandusuallyisaccompaniedwithsuch methodsofadditionalauthenticationasCVV2and3DSecure.Thevalidationofthecardholderbillingaddresscanalsobeperformedinthe process.

Uponregistration,apaymentnetworktokenforthecardisgeneratedand storedonthemobiledevicesecurely.Inadditiontothetoken,acryptographickeycanalsobetransferredandstoredonthemobiledevice,tobe usedaspartofdCVV.

Duringanm-commercepaymentthetokenvalueinsteadoftheoriginal PANissenttotheonlinestore.

Onpayinginstore,andthisiswheretheinnovativenatureofthemethod trulyshows,thetokenvaluealongsideadynamicCVV(seealsoDynamic CVV)istransmittedtoaterminalusingcontactlessmagstripedataentry mode.Thetokennumber,whichisuniquetothespecificdevice,istransmittedintheNFCbandaspartofcontactlessmagstripedataalongside additionalcryptographicevidenceintheDDpartofTrack2datavector(seesection2.4.2).Sincethedataispackedintoexisting,ISO8583compliantdatafields,contactlessPOSdevices,processorandacquirer systemsaswellascardschemenetworksfacenoissuewithtransmitting thetransactiontotheparticipatingissuerallthewaythrough.

SuchmodernmobilepaymenttechnologiesasApplePay,SamsungPayand othersrelyonthisdataflowtofacilitatecard-presentpayments.

CARD-PRESENT ENVIRONMENT III

5.3.5ApplicationSelection ...................................... 115 5.3.5.1IndirectApplicationSelection ................ 116 5.3.5.2DirectApplicationSelection ................. 116 5.3.5.3FinalSelection .............................. 117 5.3.5.4FileControlInformation(FCI) 117 5.3.6InitiateProcessing 118 5.3.6.1ApplicationInterchangeProfile 118 5.3.6.2ApplicationFileLocator 118 5.3.7ReadApplicationData 120 5.3.8OfflineCardAuthentication 120 5.3.8.1CommonStepsofOfflineAuthentication 121 5.3.8.2KeyChainofTrust 122 5.3.8.3PublicKeyRecovery ........................ 124 5.3.8.4SignedDataValidation ....................... 126 5.3.8.5StaticDataAuthentication(SDA) ............ 127 5.3.8.6DynamicDataAuthentication(DDA) ......... 127 5.3.8.7CombinedDataAuthentication(CDA) ....... 129 5.3.9ProcessingRestrictions .................................... 130 5.3.9.1ApplicationVersionNumber ................. 130 5.3.9.2ApplicationUsageControl ................... 130 5.3.9.3ApplicationEffectiveandExpirationDate .... 130 5.3.10CardholderVerification .................................... 131 5.3.10.1AmountFields ............................... 131 5.3.10.2CardholderVerificationRules ................ 131 5.3.10.3CVMResults 133 5.3.10.4ExampleofaCVMList 133 5.3.10.5OfflinePINVerification 135 5.3.10.6OnlinePINVerification 138 5.3.11TerminalRiskManagement 138 5.3.11.1OfflineAuthorizationandTerminalRisk Management 138 5.3.11.2FloorLimit 139 5.3.11.3RandomTransactionSelection 139 5.3.11.4VelocityChecking ........................... 140 5.3.12TerminalActionAnalysis .................................. 141 5.3.13GenerationofCryptogramsandIssuerAuthentication ...... 142 5.3.13.1CardActionAnalysis ........................ 143 5.3.13.2GenerateAC(GAC)Command .............. 144 5.3.14ScriptProcessing .......................................... 148 5.3.15TransactionCompletion ................................... 149

5.1Overview

5.1.1Introduction

Introducinganentirelynewcomplicatedtechnologyprofoundlyaffectscardissuersaswellasacquirersandrequiresanearlycompleterenewalofterminal, networkandcardproductioninventoryandisanexpensiveanddisruptivemove. However,intheeyesofmajorindustrystakeholdersthemovewasjustifiedfor tworeasons:combattingfraudandallowingsmarterofflineauthorizations.

Acardhavingamagneticstripeisnothardtoskimandreplicate,andasthe pricesforelectronicsplummetedandskimmingdevicesgrewsmaller,itbecame possibleforfraudsterwaiterstoswipeitontheirwaytothecashierinconspicuously.Aftersuchaswipethecardcouldbereplicatedandreusedforfraudulent purchases.

Magneticstripetechnologymadeofflinetransactionsauthorizationpossible butimposedhighrisksonschemeparticipantsasnolimitsforthenumbersor amountsofofflineauthorizationscouldbeefficientlyimposed.

Toaddressbothissuesschemeparticipantsundertookamajortechnological transitiontointegratedcircuitcards(ICCs),embeddingineffectasmallandvery securecomputerintoeachcard.

Thus,thecardbecomessmartenoughtomaintaininternalcountersinamannerindependentfromthecapabilitiesandintegrityofaparticularterminaland relyoncryptographicmethodstoauthenticatecardsandtransactions.Inaddition,asfakingachipcardisextremelyhard,issuersareabletodelegatesome authoritytothecarditselfallowingittoapprovetransactionsoffline.

Theterminal,inturn,hastobesufficientlysophisticatedtobeabletoparticipateinameaningfuldialogwiththecard,includingnotonlytheobviousability tophysicallycommunicatewiththechiponitviacontactorcontactlesslinkbut alsosupporttheappropriatecommunicationprotocolandapplication-levellogic, includingcryptographicmeansofdataencryptionandsignaturevalidation.

5.1.2“ICC”vs.“EMVcard”

Inthecontextofpaymentthe,terms“ICC”and“EMVcard”arefrequentlyused interchangeably.That,however,isimprecise.

Theterm“ICC”,ifusedmoreaccurately,referstoanISO/IEC7816compatiblechipcardalsocalled smartcard.Theterm“EMVcard”refersto acardthatiscompatiblewithaversionoftheEMVspecification.Itfollowsthat everyEMVcardisanICCbutnotnecessarilyviceversa.

Tobeginwith,allGSMSIMcardsarebuiltusingtheICCtechnologyand essentiallyareICCswithsmallerformfactors.Butevenwithoutconsideringthis exampletheareainwhichICCsareusedgowaybeyondboundariesoftheEMV standard.

Smartcardscanbeusedasmeanstoachievehighersecurityduringauthentication,forexample,tofacilitatesinglesign-oninsensitiveenvironments.Also, mostHSMsrelyonproprietarysmartcardsolutionstostorekeycomponents.

Governmentsareincreasinglyusingsmartcardsforidentification.Forexample,TurkeyhasreliedonICCsforitsdrivers’licensessince1987,andEU countriessuchasBelgiumandEstoniahavetransitionedtosmartcardgovernmentIDs.

ICCswere(andstillare,althoughdecreasingly)usedaselectronicwallets notrequiringaconnectiontoabankorprocessinghostinordertoperforma payment.

Smartcardsarealsowidelyusedastransitticketsespeciallysincecontactless technologywasintroducedandgraduallybecameaffordable.Tappingacardon aterminalismuchfasterthanhavingthebusdriverpunchaholeinamulti-ride ticket.

Furthermore,asitisdescribedinmoredetailbelow,duetothefactthatan ICCcanhostmultipleapplications,asinglecardcanperformmultiplefunctions.

Thus,manyeducationalinstitutionsaroundtheglobehaveintroducedstudent cardsprovidingsecurestudentidentificationandservingasadigitalwalletfor purchaseofgoodsandservicesaroundthecampus.Bankssometimesissuepaymentcardswithapplicationsfromseveralcardbrandsbundledtogether.Insome regionsbanksissueacombinedtransit/paymentcardthatcanbeusedbothasa transitpassandapaymentcard(suchasOysterPasscardinLondonorTroika cardinMoscow).

InsubsequentchapterswecoveraminimumnecessarysubsetofICCISO standardsandrefertoEMVstandardswhenthelattersupplantsorextendsthe former.

5.1.3ICCArchitectureOverview

Asmentionedabove,thenotionofanIntegratedCircuitCardmeansthata“small andsecure”computerisembeddedintoaplasticcard.Itsphysicalstructureis coveredinsection5.2.1.

Asoneexpectsfromacomputer,itisabletorunoneormanyapplications, andastandarddescribesmeanstoselectanapplicationandthenexchangemessageswithit.

ApplicationsutilizeanAPIprovidedbyeitheranativeoperatingsystemor aframeworkontopofit.Naturally,therearemultipleoperatingsystemsand frameworks,listinganddescribingwhichisbeyondthescopeofthebook.However,oneparticularframeworkstandsout:thereisaJavaCardspecificationdescribingaJavaeditionforsmartcardintegralchips.

Inacontact-basedscenariowhenthecardisinsertedintoareader,theterminalprovidespowertothechip,andtheterminalapplicationcommunicateswith

theICCviaphysicalcontactsonthecard.Inacontactlessscenariothecommunicationandthepowerareprovidedwirelessly.

TheICChostsafilesystemcontaining“dedicatedfiles”(similartofolders withextradata)and“elementaryfiles”(simplefiles).DedicatedfilescanbereferencedtoviaanapplicationID(seebelowonapplicationselection).Elementary filescanbeaccessedbyterminalapplicationdirectlytoretrievenecessarydata fromtheICCapplication.

Theterminalapplicationsendscommands(instructions)tothecardapplicationtowhichthelatterrespondswithstatuscodesandrelevantdata.EMV specificationdefinesasubsetofICCcommandsusedfortheinteractionwithan EMVapplication.

Furthermore,theEMVspecificationdefinesatag-level-valueformatforits data,definesallsupportedtagsandtagcombinations(EMVtemplates)aswell asaddsthenotionofDOLs(dataobjectlists)—awayforterminal-cardinteraction,whereasthecardinformstheterminalofexpectedtagsandtheirallocated lengths,andtheterminalrespondswiththeunformattedpackeddata.

Thearchitectureisdescribedinmoredetailsinsection5.2.

5.1.4Card-TerminalInteraction

Aterminalcanpossessavarietyofinputinterfaces,includingacontactlesssensor,chipreaderandmagstripereader.Acardcanbetappedontheterminal, insertedintothereaderandswipedonit.

Assumingacardsupportingallthethreeentrymodes,atappedorinserted cardinitiatestherelevantapplicationselectionandinteractionprocess.

However,asdescribedinsection2.4.4,achip-enabledmagneticstripecard containsthevalueof2or6asthefirstdigitoftheservicecode.Uponreading amagneticstripecardwiththisvalue,achip-enabledterminalmustpromptthe cardholderorshopattendanttousechipinterfaceinstead.

Itisonlyafteranattempttousethechipfailsthattheterminalshouldallow usingofthemagneticstripe,aconditioncalled magstripefallback.Tosimulate thisbehaviorduringtesting,onecouldswipethecard,then,whenprompted, insertitintothechipreaderwrongsidefirst,afterwhichtheterminal,unableto distinguishanhonestchiptransactionattemptfromsaidfake,finallyallowsthe magneticstripetowork.

Theprocessofterminal,merchantandcardholderworkingoutthedataentry methodusedduringthetransactionissometimescalled technologyselection

EachEMVtransactionisperformedbymeansofinteractionbetweenanapplicationhostedintheterminal(the terminalapplication)andanapplication hostedinthecard(the cardapplication).

Cardscarrynobatteryandexclusivelyrelyontheterminaltoprovidepower. Thus,anychiporcontactlessinteractionoftheterminalandthecardbeginswith theterminalprovidingthepowertothecard.Inthecontactenvironment,the

terminalproceedsbysendingasignalonthecard’s RST linetowhichthecard respondswithaveryshortATR(answer-to-reset)communication.

Fromthatpointanduntilthetransactioniscompleted,interruptedorcancelled,thecommunicationbetweentheterminalandthecardiscontrolledbythe terminal(see figure5.1).

5.2ICCArchitectureDetails

5.2.1ChipandAntennaHardware

Thetransitionfromamagneticstripecardtoachip-enabledonemeantadding anICCtotheusualcardmakingitaflavorofanISO7816compatiblesmartcard.

Thechipisessentiallyasmallcomputerembeddedintotheplastic.Itispoweredexternallyandcommunicateswithreaderdevicesviaasetofconductive zoneslocatedabout1cmfromthetopand1cmfromtheleftsideofthecard. Thestandarddefines8externalcontactsnumberedfromC1toC8outofwhich C4andC8arereservedforfutureuseandanotherone—C6—formerlyusedfor Vpp (EEPROMprogrammingvoltage)isdeprecated.

Thecontactsarelistedin table5.1.

TheintegratedcircuitonacontactchipcontainsROM(read-onlymemory),RAM(randomaccessmemory)andEEPROM(electricallyerasableprogrammableread-onlymemory).TheRAMiswipedbetweenactivationsofthe integratedcircuit,theROMispre-programmedduringthecardmanufacturing andtheEEPROMisrewrittenrepeatedlyduringthelifetimeofthechip.

Table5.1:ISO7816chipcontacts

ContactDesignationUse

Powerconnectionthroughwhichvoltage issuppliedtothechip. C2 RST

C1 Vcc

Resetlinethroughwhichthechipcanbe resettoitsinitialstate. C3 CLK

Clocksignallinethroughwhichthechip microprocessoranditscommunication lineissynchronizedwiththereader device.

Groundlinetoprovidecommon electricalgroundbetweenthechipand thereaderdevice.

C6 Vpp Programmingpower

connection—formerlyusedforolder cardsandisdeprecatednow. C7 I/O

Input/outputlinethatprovidesthe half-duplexcommunicationbetweenthe chipandthereader. C8 RFU Reservedforfutureuse.

Thecontactlesscardcontainsasomewhatdifferentintegratedcircuitandis sometimescalledPICCorProximityIntegratedCircuitCardandanembedded antenna.ISO/IECstandard14443governscontactlesscardsandreaders.

Contactlesscardsoperateatradiofrequencyof13.56MHz(RFIDfrequency) andNFC(Near-FieldCommunicationsstandard)ispartiallycompatiblewith ISO/IEC14443,allowingNFC-capabledevicestooperateascontactlesscards. Thefeatureenablesmobilein-storepaymentapplications.

Contactlesscardsreceivetherequiredpowerforoperationfromthecurrent inducedintheantennabytheelectromagneticfieldoftheproximityreader.There aretwocontactlesscardtypes,andtheyaredenotedinthestandardsasTypeA andTypeB.Amongthedifferencesinsignalmodulationbetweenthetwotypes, theradiofieldofthereaderisturnedoffforshortperiodsoftimeduringthesignal transmissionforTypeAcards,andsoaTypeAPICCmustcontaincapacitorsto sustainthefunctioningofthecircuit.

5.2.2ICCFileSystem

Regardlessoftheunderlyingoperatingsystemimplementation,eachICCcontainsafilesystemwhoseorganizationisdefinedbyISO/IEC7814-4.

TheICCcancontaintwotypesoffiles:elementaryfiles(EF)anddedicated files(DF).ThefilesystemishierarchicalhavingDFsroughlycorrespondingto foldersandEFs—tofilesofafilesystem—onapersonalcomputer.Thatis,a DFcancontainsub-dedicatedfilesorsubfoldersandbothatop-levelDFandits subfolderscancontainmultipleelementaryfiles.

Therootdedicatedfileofthehierarchyiscalledthemasterfile(MF).

AsanICCcancontainmultiple“folders”andapplications,theEMVstandard definesADF(applicationdefinitionfile)servingasadatacontainerorahome folderofasinglecardapplicationandDDF(directorydefinitionfile)isafolder containingotherfoldersorapplications.Specificsub-DFsandEFsunderanADF containdataspecificforandinternaltothatapplication,whileEFsunderthe masterfile(MF)cancontaindatacommontoallapplicationsonthecard.

5.2.2.1DedicatedFilesandAID

Adedicatedfilecanbereferencedusingeithera fixedfileidentifier(FID),an applicationidentifier(AID) orafullpathoffixedfileidentifiers.Thestandard actuallyspeaksof“DFName”ratherthanapplicationID,butfrompracticalpoint ofviewthetermsareinterchangeable.

TheFIDisa2-bytevaluewhichcanbethoughtofasareferencetophysical locationofthededicatedfile.Forinstance,themasterfilealwayshasFIDof 0x3F00,thefirstdedicatedfileimmediatelybeneathithasaFIDof0x7F01and sotheforthsoaterminalneedstoknowtheexactstructureandorderoftheDF treeonthecardtobeabletoreferenceitcorrectly.Thatrequiresacertainlevel

ofknowledgeofcardinternalscomplicatinginteroperability.Incontrasttoit,the AIDorDFnameisabytestringofupto16byteswhichdoesnotdependonthe applicationlocationinthechipfilesystem.

Tobetterunderstandthedifferencebetweenthetworeferencemethods,considerthetaskofinvokingabrowserfromwithinaprogramonapersonalcomputertonavigatetoawebsite.Knowingthefullpathtothebrowserexecutable isonewayoflaunchingit,butitrequiressomeknowledgeregardingbrowsers deployedontheparticularmachineaswellastheirexecutablelocationsandfilenames.ThatissimilartoreferencingadedicatedfileusingFIDoranFIDpath.

Alternatively,manyoperatingsystemsprovideURLhandlersandaprogram couldinvokeagenericURLhandlerandpassthewebpageaddresstoitleaving ittotheOStolocateandlaunchthecorrectbrowser.

TheAIDcanbeeitherregisteredorproprietary.Itsformatandregistration processaredefinedinISO/IEC7814-5.

Obviously,theproprietaryAIDcanbeofarbitraryformatoccupyinganywherebetween1to16bytes.

AregisteredAIDconsistsoftwoparts:theregisteredapplicationprovider identifier(RID)andtheproprietaryapplicationidentifierextension(PIX).The rationalebehindthatisasfollows:first,toavoidAIDscollidingeachapplication providerisassignedanRIDbyaregisteringentity.Thentheapplicationprovider canoptionallyusethePIXtoidentifyindividualapplications.

ThestructureofastandardcompliantAIDisshownin figure5.2

Figure5.2:ISO/IEC7814-5compliantAID

CATdenotesregistrationcategory.Itisa4-bitfieldwithallpossiblevalues listedintheISO/IEC7816-5standard.Twoofthoseareworthmentioninghere: AforinternationalregistrationandDfornationalregistration.

Inthecaseofinternationalregistration,theRIDconsistsofa4-bitregistration categoryindicator,withAcodedas1010andtheidentifieritselfconsistingof9 BCDdigitsspanning36bits.ThePIXthatcanoptionallyfollowtheRIDcanbe anywherebetween0to11bytes(inwholebytes).

Inthecaseofnationalregistration,theRIDconsistsofa4-bitregistration categorywithindicator,Dcodedas1101,thecountrycodeofthenational

registrationauthorityintheformofISO3166-1numericcountrycodeinBCD format,spanning12bits,andthenationalidentifierinformofasingleormultiple fieldsasdefinedbythespecificregistrar.

Forexample,aninternationalAIDcanlooklike A0000000031010 (thisis aVisastandardapplicationID).Here A meansinternationalregistration,digit sequence 000000003 istheRIDanddigits 1010 arethePIXforthisspecific application.

Similarly,hereisanexampleofadomesticAID: D268000001 D meansnationalregistrarand 268 istheISOcountrycodeofGeorgia.ThatparticularAID isreservedbytheMinistryofFinanceofGeorgiaforfiscalcashregisters.

5.2.2.2ElementaryFiles

Cardelementaryfilescanbeofseveraltypesandbeusedforoneoftwopurposes. Theyarelistedbelowforthesakeofcompleteness,however,thetechnicaldetails arerarelyrequiredbyaprocessororanacquirerasthespecificsareabstracted awaybytheterminalandcardapplications.

Anelementaryfilecanbeeither internal (usedbyapplicationonlyandcontainingimplementation-specificand/orsensitivedata)or working (containing datausedbytheterminalapplicationduringadataexchangewiththecard).

AnelementaryfilecanfurthermorebeofoneofthefollowingtypesasdescribedinISO/IEC7816-4:

Transparent, consistingofasequenceofbytes.Itistransparenttotheoperating system,asitsformatisrawdatathecardOSdoesnotneedtohandle referringitscontentsas-istotheinvokingapplication.

Linearfixed, consistingoffixed-lengthrecords.

Linearvariable, consistingofvariable-lengthrecords.

Cyclic, atypeoflinearfixedfilehavingacyclicstructure:afterthefileisfull andeachrecordhasbeenwrittentoitanysubsequentattempttowritea recordoverwritestheoldestrecordinthefile.

ElementaryfilescanbereferencedviaeitheraFID(a2-bytevalue)orashort fileidentifier(SFI),whichisanumberbetween1and30.

ToreferenceanelementaryfilewithitsFID,aterminalmustknowitinadvance.Thatrequiresawarenessofthecardapplicationinternalsandisabarrier forinteroperability.Duetothat,insuchinteroperableenvironmentsasthoseconformingtoEMVspecificationstheothermethodispreferred.

AsfortheSFImethod,some(maybenotall)elementaryfilesonacardare assignedashortnumberthatcanbecommunicatedtotheterminalintheform ofasinglefilelisting.Then,theterminalcanusetheshortcutstoreferenceto individualfiles.

5.3FlowofaChipTransaction

5.3.1Overview

Throughoutinteraction,theterminalkeepstrackofthetransactionstatusandthe resultsofvariousverificationstepsinspecialregisters,TVR(TerminalVerificationResult)andTSI(TransactionStatusInformation).

Priortotheterminalapplicationstartingtointeractwiththecardapplication, thelatterneedstobechosenfromthelistofapplicationsavailableonaparticular card.Thestepiscalled applicationselection.Acardcancontainaquickindex ofallEMVapplicationsonit(calledPSEwhichstandsforPaymentSystem Environment),oraterminaldeterminesavailableapplicationsbyusingitsown internalsupportedlistandqueryingforcardapplicationsonebyone.Thestepis describedinmoredetailinsection5.3.5.

Aspartoftheapplicationselection,theterminalcangetalistofdatafields thatthecardapplicationrequirestoprocessthetransaction.Theterminalsends thedataprescribedbythelisttothecardapplicationtoinitiatethem.Thestepis called initiatingapplicationprocessing andisdescribedinmoredetailsinsection5.3.6.Duringtheinitiation,theterminalalsoreceivesasetofflagsdescribing varioussupportedfunctions(mostlyrelatedtoauthenticationandriskmanagement),the applicationinterchangeprofile,andasmall“catalog”ofapplication elementaryfiles,the applicationfilelocator withdatarequiredfortransaction processing.

Oncethelistofnecessaryapplicationelementaryfilesisknowntotheterminalapplication,it readsapplicationdata,combinesallthedatafromallfilesinto asingledataobjectsheapandvalidatesthepresenceofmandatorydataobjects init.Seesection5.3.7fordetails.

Uponreadingapplicationdatasuccessfully,theterminalcanperformthe cryptographic offlinecardauthentication.SeveralmethodsofvaryingcomplexityareavailableaccordingtotheEMVstandardandtheterminalpicksthemore advancedoneoutofthelistofmutuallysupportedones.Theprocessisdescribed insection5.3.8.

Afterthetheterminalandthecardnegotiatedtheauthenticationmethod,the terminal checksprocessingrestrictions,verifyingtheapplicationversion,theapplicationeffectiveandexpirydateandthevalidityofthetransactiontypeforthe cardapplication.Thisstepisdetailedinsection5.3.9.

Oncetheterminalmakessurethatthetransactioncanproceedaccordingto theprocessingrestriction,itconsultsthelistof cardholderverificationmethods (theCVMlist)andtherulesfortheirselection,pickingthefirstonethatmatches theterminalcapabilities,theterminalandrequiredtransactiontypeandtherequestedtransactionamount.Refertosection5.3.10.2foradescriptionofthis step.

WhenEMVtechnologywasfirstintroduced,alargeproportionofterminals werenotabletoauthorizeeachtransactiononlinebysendingittotheissuer.

Consequently,thestandardallowsofflineauthorizationofcardtransactionswhile providingguidingrulesonwhentheterminalshouldgoonlineforauthorization nonetheless.Theprocessofapplyingtherulestodeterminewhetheratransaction mustbeauthorizedonlineiscalled terminalriskmanagement andisdescribed inmoredetailsinsection5.3.11.Thestepcanbetakenanywherebetweenthe momenttheterminalreadstheapplicationdataandthemomentitfirstrequests anapplicationcryptogram.

Uponcompletingcardholderverificationandterminalriskmanagement steps,theterminalandthecardnegotiatethemethodtoapproveordeclinethe transaction.Theterminalmakesthepreliminarydecisionbytakingintoaccount theacquirerpreferences,theissuerpreferencesandtheresultsoftheprevious stepsassembledinTVR.Theprocessiscalled terminalactionanalysis andis describedinsection5.3.12.

Oncetheterminalhasmadeapreliminarydecision,itcommunicatesitto thecardintheformofaGENERATEACcommand(GAC).Thecommandcan alsoincludesomedataforofflinecardauthentication(seesection5.3.8.7).The cardandtheterminaldecidehowtoprocessthetransactionfurther.Thereare severaltypesofcryptogramswhichtheterminalcanrequestandthecardcan decidetodowngradeinresponse(forexample,refusingtoperformanoffline authorizationandforcinganonlineone).Iftheauthorizationisperformedonline, theterminalcanfurtherensuretheissuerauthenticitybyeitherusingoptionally theEXTERNALAUTHENTICATEcommand,followedbysecondGENERATE ACcommandtothecardorbycombiningthetwo.Theprocessisdescribedin 5.3.13.

Incaseofatransactioninvolvingonlineprocessingtheissuercansendan updatetothecard,securelymodifyingthecard’sdata(resettingcounters,thresholds,modifyingPINvalueorperformingothersolution-specificactivities).Such anupdateiscalledan issuerscript andtherearetwotypesofthem:scriptssent tothecardbeforeanauthorizationresponse,andthosesenttothecardafteran authorizationresponse.Theprocessisdescribedinsection5.3.14.

ThesecondcalloftheGENERATEACcommandconcludesacontactEMV transaction.

5.3.2CardInterface

5.3.2.1Answer-to-Reset

Thecardcommunicateswiththeterminalafterithasbeeninsertedintoitor tappedonitbyreceivingitscommandsandreturningcommandresponses(see alsosection5.1.4).

AllISO/IEC7816standard-compliantcardssharethesamecommunication formatbetweentheterminalandthecard.Thespecificelectronicsignalsand transmissionprotocolsaredescribedinpart3oftheISO/IEC7816standard.

However,forthepurposeofabetterunderstandingofthecardinterface,it isimportanttohighlightafewkeyfactsaboutthelower-leveldatatransmission thatmaynotbeentirelytransparentatahigherapplicativelevel.

Forthesakeofsimplicityconsideracontactscenario.

Afterthecontactsareconnectedtoacard-acceptingdeviceandpowerand clocksignalsareprovidedtothecard,the I/O contactisputintothereceiving statebythedeviceanditsendsasignaloncard’s RST contact.Thesignalcauses aresetofanytransientstateofthecardanditsinitializationinpreparationfor thecommandexchangethatfollowsit.

UponcompletingtheresetthecardtransmitsbackviatheI/Oline,the ATR (Answer-to-Reset)messagewhichamongsomeadditionaldatalistssupported datatransmissionprotocols.Theprotocolsareencodedasa4-bitvaluedenoted asT.

ThetwomostrelevantpossiblevaluesofTareT=0andT=1,whichdenote asynchronoushalfduplexcharactertransmissionprotocolandasynchronoushalf duplexblocktransmissionprotocol,correspondingly.

TheT=0character(byte)protocolistypicallysupportedbyweakercard hardwareanditdoesnotallowdatatransmissioninbothcommandanditsresponse(seesection5.3.2.2).TheT=1blockprotocolhasnosuchrestriction.

5.3.2.2CommandandResponse

Anyapplicationprotocolisimplementedasaseriesofcommandsandcommandresponses.Eachsuchmessageiscalledanapplicationprotocoldataunit (APDU).AcommandiscalledC-APDU(commandapplicationprotocoldata unit)andisalwayssentfromtheterminalapplicationtothecardapplication.The cardapplicationrespondstoacommandwithR-APDU(theresponseAPDU).

Cardcommandsaregroupedintoinstructionclasses.Tospecifyacommand, itisnecessarytosenditscommandclassdenotedas CLA andthespecificinstructioncodewithinthatclassdenotedas INS.Theprotocolallowssendingtwo single-byteparameters(P1 and P2)witheachcommandaswellasprovidingan additionalvariable-lengthfieldwithadditionalparameters.

TheR-APDUforeachcommandconsistsofanoptionalvariable-lengthdata fieldandamandatorytrailerwithtwostatusbytes, SW1 and SW2 containingthe commandresult.

ThelayoutofthetwoAPDUsisshownin figure5.3.Optionalfieldsare enclosedinsquarebrackets.

TheC-APDUfieldsare: CLA command(instruction)class,mandatory1-bytefield. INS command(instruction)code,mandatory1-bytefield.

P1,P2 mandatorysingle-byteparametersoftheinstruction.Ifaspecificinstructiondoesnotrequiretheparameterstheymuststillbesent.

Figure5.3:LayoutofC-APDUandR-APDU

Lc optionallengthfield,indicatingnumberofbytesinthefollowingdatafieldof thecommand.AccordingtotheISO/IEC7816-4standardthefieldcanbe 1or3bytes,butinEMVapplicationsonly1-bytelengthvaluesareused. Ifthefieldispresent,itmustbefollowedbythedata.

Data optionaldatastringprovidedasadditionalinputdatatothecardapplication.

Le optionallengthfieldofupto3bytesspecifyingthemaximumlengthofthe responsedatafieldinbytesexpectedforthecommand.TheEMVstandard specifies1byteasthefieldmaximumlength.Ifthefieldispresentand equaltozero,thentheterminalisreadytoreceivethemaximum(256) bytesofdataintheresponseAPDU.

IfaC-APDUcontainsasinglebyteintheoptionalbody,itisassumedtobe Le TheR-APDUfieldsare:

Data optionalvariable-lengthbodywhoselengthmustbelessorequalto Le if thelatterhasbeenspecifiedinthecommand.

SW1,SW2 mandatorystatuswordsoccupying1byteeach.

TheISO7816standardonlydefinesthebasiccommandsanycompliantcard mustsupport.FurtherstandardssuchastheEMVcardstandarddefineadditional commandsthatshouldbealsosupported.Finally,eachoperatingsystemand applicationcanandoftendoeshaveprivateusecommandsonlysupportedbythe particularbrandofcardOSandbythespecificapplication.

5.3.2.3CLAFormat

TheCLAbyteformatassignsitsmostsignificantnibbletocommandtype.The EMVspecificationonlyusestwooutofthepossiblevaluesforthatnibble, namely, 0 forinter-industrycommands(thosesharedwithISO/IEC7816standard)and 8 forEMVproprietarycommands.

Theleastsignificantnibblehasbits3and4allocatedtodefiningthesecure messagingformatandbits1and2usedtospecifythelogicalchannel.

TheEMVspecificationonlyusestwotypesofsecuremessagingformatdenotedasFormat1andFormat2.

Standard-compliantsecuremessagingdenotedasFormat1whereeachelementofthecommanddatastrictlycorrespondstoBER-TLVformat(seesection 11.6),encipheredorplain-textdatafieldsarepassedinappropriatetags,andthe messageauthenticationcodeisprovidedasyetanotherstandardtaggedvalue. Thevaluesforbits4and3oftheleastsignificantnibbleof CLA forthisformat are 11.

ProprietarysecuremessagingdenotedasFormat2assumesthatthedatadoes notcomplywithBER-TLVencodingrules.Itispassedtothecardapplication asis,andthecardandterminalapplicationshouldbeabletohandletheformat details.TheMACforsuchamessagemustalwaysbethelast4to8bytesofthe data.Valuesforbits4and3ofthe CLA nibblefortheformatare 01.

TheISO/IEC7816-4standardallowsmultiplelogicalchannelstoexistduring asingleterminal-cardsessionsimultaneouslyallowinguptofourparallellinks betweentheterminalapplicationsandthecardapplications.TheEMVstandard onlyutilizessinglelogicalchannel,sothevaluesforbits2and1ofthelesser CLA nibblearealways 00.

ItfollowsthatinanEMVapplication,theCLAcanonlyassumehexadecimal valuesof 04, 0C, 84 and 8C

5.3.2.4INSValues

ThefulltableofsupportedINSvaluesaswellasthevaluesreservedforfuture usecanbefoundinBook3oftheEMVspecifications,andsomespecificcommandsarementionedfurtherwhenappropriate.However,toillustratetheprinciplesofINScodeallocationandcommandlistutilization,considerthefollowing examplesgivenin table5.2.

Thetableshowstwocommands:theSELECTcommandthathelpspickan applicationclosetothebeginningofaterminal-cardinteraction,andtheGET PROCESSINGOPTIONScommandthatisthemainEntryPointtoanEMV transactionflow.AsdefinedbythemostsignificantnibbleoftheSLA,theformer isISO-defined,andthelatterisEMV-specific.

Table5.2:SampleINSvalues

5.3.2.5SW1andSW2

AllthevalidvaluesofSW1andSW2statuswordbytesaredefinedinISO/IEC 7816-4standardandmentionedinEMVBook1andBook3orboth.

Theoutcomeofacommandexecutioncanbeidentifiedbyexamining SW1. Table5.3 containsthemajorgroupsofstatuswordsvalues.

5.3.2.6SFI

Asmentionedpreviously(seesection5.2.2.2),forthesakeoftheaccesssimplicity,elementaryfilesontheICCcanbeaccessedusingaShortFileIdentifier orSFI.Duringtheapplicationselectionprocess(seesection5.3.5),theterminal learnstheSFIoftheapplicationelementaryfile(AEF)fortheapplicationitis supposedtoaccess.

TheAEFisalinearfixedorvariable-lengthfilewitheachrecordcontaining tag70template(seesection5.3.3fordetails).UponlearningtheSFIofthefile theterminalshouldaccessitusestheREADRECORDcommandtoretrievethe datafromit.

TheEMVstandardreservesAEFswithSFIbetween1to10forEMVstandarddata,SFIranges11to20arereservedforproprietarydataasspecifiedby individualpaymentsystemsandranges21to30aredesignatedfortheissuerspecificelementaryfiles.

5.3.3EMVDOLsandTags

TheEMVspecificationfordatavaluesisbasedonBER-TLVformat(seesection 11.6).Thatsimplifiesinteroperabilitygreatlyasthedataformat(itsorder)is

Table5.3:SelectedSW1andSW2values

flexibleand,furthermore,aterminalorcardapplicationcanparseastreamof databyloopingthroughthestepsoftheparsingtag/parsinglength/readingtag value.

However,afixedformathaslessoverheadandcanbeparsedfasterprovided thatitiswellknowntoboththeterminalandthecardapplications.TheEMV standardcontainsthemeansforacardtorequestasetofdatafieldstobeprovided tothecardapplicationfromtheterminalinafixedformat.Forthatpurpose,the EMVstandardhasdefinedDOL(standsfor dataobjectlist).

ADOLisbasicallyalistoftagsandlengthstheterminalisexpectedtoprovideinreturn.UponreceivingtheDOL,theterminalshouldgatherandconcatenatealltherequesteddatatrimmingorpadwithzerosthefieldswhicharetoo long,tooshortorabsentfromtheterminal.

Inotherwords,theTLV(tag-length-value)ofdataelementsaresplitbetweenthecardandtheterminal.ThecardholdsalistofTL’sconcatenatedas TL1 ||TL2 ||...||TLn ,andtheterminalisexpectedtoprovideastringofV’s concatenatedas V1 ||V2 ||...||Vn .

ThefollowingDOLsaredefinedintheEMVspecification:

ProcessingOptionsDataObjectList (PDOL)usedwiththeGETPROCESSINGOPTIONScommand.Seesections5.3.5.4and5.3.6.

CardRiskManagementDataObjectLists (CDOL1andCDOL2)usedwith theGENERATEACcommandtogenerateapplicationcryptograms.

TransactionCertificateDataObjectList (TDOL)usedtogeneratetransactioncertificatehashvalues,sometimesalsousedfortheapplicationcryptogramsgeneration.

DynamicDataAuthenticationDataObjectList (DDOL)usedwiththeINTERNALAUTHENTICATEcommand.

IndividualEMVtagscanbeseenasfieldsofaparticularscalardatatype. Thetagsaregroupedintotemplatesroughlycorrespondingtocompounddata types.TheDataElementsDictionarysectionoftheEMVBook3,Application Specification,listsallthepossibletemplatesandtagsinasinglecomprehensive table.Thetable,asseeninversion4.3oftheEMVspecification,containsthe followingcolumns:

Name specifiesdataelementname.

Description specifiesdataelementdescription.

Source specifieswhetherthetagcanoriginatefromtheICC,theterminal,the issuerortheircombination.

Format specifiesthefieldformat,anditsconventionsarealsobroughtinEMV Book3,ApplicationSpecification.

Template containsthetagortagsofEMVfieldtemplateswhichcancontainthe currentitemasasub-element,ifapplicable.

Tag specifiestheactualtagvalueforthedataelement.

Tounderstandtheconventionbetter,letusfollowtheexampleoftag9F42. Accordingtothespecification,itistheApplicationCurrencyCodedataelement withdatalengthof2.Itisapackednumeric3-digitnumber,anditdenotesa currencycodeaccordingtoISO4217.Fromthetablewealsolearnthatthevalue originatesfromthecard(theSourcecolumnsaysICC).Finally,lookingatthe Templatecolumnweseethatthetagcanappearaspartoftemplate70or77.

Tolocatethefields,itispossibletousetheEMVspecificationdataelement tablebytagnumber.Forinstance,accordingtothetabletheEMVdataelement havingtagnumber70istheREADRECORDresponsemessagetemplate.Thus, weknowthattheApplicationCurrencyCodecanbereturnedbytheREAD RECORDcommand.

5.3.4TerminalVerificationResults(TVR)andTransaction StatusInformation(TSI)

Duringprocessingofasingletransactiontheterminalstorestheresultsofvarious stepsanddecisionsintwostatusregisters:TSIandTVR.

TheTransactionStatusInformation(TSI)contains2bytesofwhichonly first6bitsareused.Thebitsaresetaccordingtothestepsperformedbythe terminalduringthetransactionstartingattheofflinedataauthentication(bit8), followedbythecardholderverification(bit7),cardriskmanagement(bit6), issuerauthentication(bit5),terminalriskmanagement(bit4)and,finally,issuer scriptprocessing(bit3).Therestoftheregisterbitsarereservedforfutureuse.

TheTSIcontainshigh-levelindicationsofcompletedtransactionstageswhile moredetailsaboutthedecisionsandchecksarestoredintheTerminalVerificationResults(TVR)registerconsistingof5byteseachroughlycorrespondingto astageinTSI.

Byte1oftheTVRcontainsflagsforofflinedataauthenticationresults(e.g., bit7ofthebyteissetiftheSDAhasfailed,seesection5.3.8.5,forexample), byte2containsflagsforvariousprocessingrestrictions(forexample,bit6is setiftheapplicationisnotyetactive,date-wise),byte3containsthecardholder verificationflags(suchasbit3,“OnlinePINentered”),byte4containsbitsfor terminalriskmanagementdecisions(seesection5.3.11),andbyte5capturesthe issuerauthenticationandscriptprocessingflags.

TheTVRregisteriseventuallyusedtodeterminewhetherthetransactionis tobedeclinedoffline,authorizedofflineorsenttotheissuerforauthorization byapplyingbitmaskstoitsvalueandthusdeterminingthecourseofaction (seesection5.3.12).TheEMVstandardalsorecommendsincludingtheTVR

inCDOL1/CDOL2valuessentasaninputtotheGENERATEAPPLICATION CRYPTOGRAMcommand(seesection5.3.13.2).

5.3.5ApplicationSelection

TheApplicationSelectionprocessisdescribedintheEMVBook1,ICCtoTerminalInterface(asopposedtotherestofthetransactionflowhandledinthe EMVBook3,ApplicationSpecification).

AsanICCcanhostmultipleapplicationstheterminalhastoselectoneof themtocommunicatewithduringtheparticulartransaction.Toachievethatthe terminalbuildsacandidatelistandthenselectstheonethatitisgoingtointeractwithduringthesession.Theterminalalsolearnssomedetailsregardingthe applicationandthedataitrequiresduringtheselectionprocess.

TheEMVstandardprovidestwosupportedwaystoenumerateapplications presentonanICC.Aterminalcaneithertrytoreadaspecialfile,thePayment SystemEnvironment(PSE),usingasequenceofREADRECORDcommandsor querythecardforapplicationsonitwithasequenceofSELECTcommands.

AccordingtotheEMVstandardthepresenceofPSEisnotmandatory.If present,itisafilehavingaDFnameof 1PAY.SYS.DDF01.AterminalthatsupportsapplicationselectionviathePSE(alsocalled indirectapplication selection)firstissuesaSELECTcommandtryingtolocateitandifsuccessful canreadandparseitbuildingthelistofitscandidateapplicationsintheprocess. APSEcancontainmultipleADFs(containingAIDintag61)andDDFs(containingitsDDFnameintag9Dandinadditionsometimesincludingmultiple subordinateADFsandDDFs).

IfthePSEisnotpresentonthecardortheterminalisnotprogrammedto utilizeit,theterminalhastoquerytheICCforthelistofapplicationsknown totheterminalonebyoneusingtheSELECTcommand.Theprocessiscalled directapplicationselection andcanbequitelengthyastheremightbeabig numberofapplicationsthatappearontheterminallistbutarenotsupportedby theparticularcard.TheterminalhastosendoneAIDafteranother,andthecard returnsasuccessfulresponsetoeachSELECTcommandiftheAIDparameter oftheSELECTcommandmatchesanAIDofthecardapplicationprecisely.The processiscalled complete or fullnamematching.

TooptimizetheprocedureincaseofsuchascenariotheEMVstandardallows optional partialnamematching ofapplications.

Inthecaseofpartialmatchingtheterminalcouldsendaprefix(partialname) insteadofsendingafullapplicationnametotheICCandtheICCreturnsapplicationswhichfullAIDsmatchtheprefix.

Considersomescenariosforvariouscaseswithdirect/indirectapplicationselectionandcomplete/partialnamematchinggiveninsections5.3.5.1and5.3.5.2. ItisassumedthattheterminalsupportsPSEandpartialnamematching.Notethat theflowsonlycoverbasicscenariosandarenotprovidedforthecaseswhenan

applicationorcardisblockedandtheydonotdescribeanyterminal-sidelogic associatedwiththerulesforaddinganAIDtothecandidatelist.

5.3.5.1IndirectApplicationSelection

1.TheterminalsendsaSELECTcommandwithfilenamevalueto 1PAY.SYS.DDF01 and P2 parametersetto“firstandonlyoccurence”.

2.Thecardrespondswith SW1/SW2 wordssetto9000(Success),anddata containingFCIofthePSE(tag6F).ThisresultmeansPSEispresenton thecard.

3.TheterminalsendsaREADRECORDcommandwith P1 setto1(first recordinfile)and P2 settotheSFIoftheDIRfileofthePSE(asreturned inFCI).

4.Thecardrespondswith SW1/SW2 setto9000(Success)andwithFCIof theentry(tag6F).

IftheentryisanADF(containstag4F),theapplicationshouldjointhe candidatelist.IftheentryisaDDF(tag9D),itisdescendedinto,likea filesystemfolder:terminaladdressesitwithSFIreceivedinpreviousstep, thenscansitwithREADRECORDcommand.

5.TheterminalrepeatedlysendsREADRECORDcommandwith P1 setto n(forn-threcordinthefile)and P2 settotheSFIoftheDIRfile.

6.Thecardrespondswith SW1/SW2 setto6A83(“WrongparametersP1P2; recordnotfound”).

Thisresultmeansthereisnon-threcordinthefile.

5.3.5.2DirectApplicationSelection

1.TheterminalsendsaSELECTcommandwithfilenamevalueto 1PAY.SYS.DDF01 and P2 parametersetto“firstandonlyoccurence”.

2.Thecardrespondswith SW1/SW2 setto6A82(“WrongparametersP1P2; filenotfound”).

ThismeansthereisnoPSEonthecard.

3.TheterminalsendsaSELECTcommandwiththefilenameparameterset tothefirstAIDonthelistofAIDstheterminalsupports.

4.Thecardrespondswith SW1/SW2 setto9000(Success),butthereturned AIDislongerthantheoneprovidedbytheterminal.

Thismeansthatthecardhasperformedpartialmatchingontheapplication IDprefix.

5.TheterminalsendsaSELECTcommandwithfilenameparametersetto thesameAIDasbefore,and P2 setto02(Nextoccurence).

6.Thecardrespondswith SW1/SW2 setto9000(Success)andreturnsanother matchingAID.

TheterminalrepeatedlysendsaSELECTcommandwithfilenameparametersettothesameAIDasbefore,and P2 setto02(Nextoccurence).

7.Thecardrespondswith SW1/SW2 notequal9000(Success).

ThismeanstherearenomorematchingAIDsonthecard.

8.TheterminalcontinueswiththenextAIDitsupports.

5.3.5.3FinalSelection

Uponcompletingthelistofsupportedcandidatesandassumingthatthereare someapplicationssupportedbyboththeterminalandthecard,theterminalcan eitherpromptthecardholdertoselectanapplication,confirmtheapplicationuse ormakethechoiceautomatically.

TheFCIofeachapplicationincludestag87,“ApplicationPriorityIndicator”, determiningforeachapplicationwhetheritsuserequiresthecardholderconfirmation,aswellasdefiningtheorderinwhichthelistofapplicationsshouldbe presentedtothecardholder.

ThisprocessiscoveredinmoredetailintheEMVBook1,subsection12.4, FinalSelection,ofsection12,ApplicationSelection.

Oncetheapplicationtobeusedisidentified,theterminalsendsaSELECT commandtofinalizetheselectionreceivingtheapplicationFCIinthecommand response.

Itisworthnotingthatsuccessfullyselectinganapplicationdoesnotguarantee thattheterminalisactuallyfullycompatiblewithit.Itispossiblethatduringthe ProcessingRestrictionsstep(seesection5.3.9)theterminalmightdiscoverthat itcannotsupporttheapplicationversion.

5.3.5.4FileControlInformation(FCI)

TheFCIcancontainseveraloptionalelementswhichcanbefoundintheEMV Book3,AnnexADataElementsDictionaryundertemplateA5.

OptionalelementsunderFCIinclude“LanguagePreference”(tag5F2D)containinganorderedlistofpreferredinterfacelanguagestheterminalshoulduse whilepresentingpromptstothecardholder.

Therearealso“ApplicationPreferredName”(tag9F12)and“IssuerCode TableIndex”(tag9F11)elementsdefiningtheapplicationnameandthecode tableinwhichtheapplicationnameshouldbeshowntothecardholderonthe terminaldisplay.

Asforthosethreeelements,issuerscaninfluencecustomerexperiencein multi-languageenvironmentsorwhenthecardholderisabroad:thus,forexample,anownerofanIsraeli-issuedcardtravellinginFrancecanseetheterminal promptsinEnglish.

TheFCIcanalsocontainthedataelement“ProcessingOptionsDataList (PDOL)”intag9F38.Theelementisusedtoinitiatetheapplicationprocessing (InitiateProcessing)andcontainsalistoftag-lengthidentifiersofdataelements theterminalhastoprovide.

Thelistusuallycontainsdataelementsdescribingtheterminalenvironment, itstypeandcapabilities,thecountryorthemerchantcategorycodeandispersonalizedonthecardbyitsissuer.

5.3.6InitiateProcessing

ThisstepisdescribedintheEMVBook3,ApplicationSpecification.

Toinitiateprocessingtheterminalresetsitsinternalstatusregisters(TVRand TSI,seesection5.3.4)andsendstheGETPROCESSINGOPTIONScommand (colloquiallyreferredtoasGPO).

TheGPOcommandhasasingledataobjecthavingtag83.IfnoPDOLis availableintheapplicationFileControlInformation(seesection5.3.5.4),the elementissentempty.Otherwise,thevaluesofdataelementsrequestedinPDOL arepaddedasneededandconcatenatedtoformasinglestringofdata(see5.3.3 forillustration).

InresponsetotheGPOcommandthecardapplicationrepliestoitwithits supportedapplicationfunctionsinthebusinesscontextandthedataregarding availableapplicationelementaryfiles(AEFs)indetail.Theformerisreferredto as ApplicationInterchangeProfile (AIP)andthelatteris ApplicationFileLocator (AFL).

Thedetailscanbeprovidedeitherinconcatenatedformundertag80orunder tag77inseparatetags,tag82forAIPandtag94forAFL.

5.3.6.1ApplicationInterchangeProfile

TheAIPconsistsof2bytesofwhichthefirstoneisonlycurrentlyinuse.The bytecontainstheindicationofsupportedstaticanddynamicofflinecardauthentication,cardholderverification,supportofissuerauthenticationandflagforterminalriskmanagement.

Table5.4 describestheAIPbitsfromleftmosttorightmost.Ifabitissetto 1,theappropriatefunctionissupported.

5.3.6.2ApplicationFileLocator

TheAFLcontainsanarrayofentriesof4-bytelength,eachdescribingthelocationofdataentriestheterminalshouldreadfromthecard.

Theentriesarestructuredasfollows:

Byte1encodestheSFI(seesection5.3.2.6)oftherelevantapplication elementaryfile(AEF).

Bytes2and3encodethefirstandlastAEFrecordtheterminalshould useforprocessing.

Asnoteveryrecordshouldbeconsideredforthepurposeofofflinestatic dataauthenticationasopposedtooverallprocessing,byte4specifiesthe lastAEFrecordthatshouldbeusedforofflinestaticdataauthentication.

Theterminalusesthedatainthefilelocatortoreadandparserecordsfrom applicationelementaryfilesatthenextstepofanEMVtransactionorReadApplicationdata(seesection5.3.7).

Theterminalalsoreliesoneachentry’sbyte4tocomposeadataauthenticationinputvectorbytesequenceusedduringofflinestaticcardauthentication(see section5.3.8.5).

Forexample,ifanentryhastheformof 0D010604,theterminalshould accessfileidentifiedbySFIof0Dusingtherecordsfromfirsttosixthforits generalapplicationdataneedsbutonlyuserecords01to04forofflinedataauthentication.

Table5.4:StructureofApplicationInterchangeProfile

BitUsage

Bit8Reservedforfutureuse

Bit7

Bit6

SDAsupported.Theapplicationsupportsofflinestatic datacarddataauthentication(seesection5.3.8.5).

DDAsupported.Theapplicationsupportsoffline dynamicdatacarddataauthentication(seesection 5.3.8.6).

Bit5Cardholderverificationissupported.Seesection5.3.10.

Bit4 Terminalriskmanagementistobeperformed.See section5.3.11.

Bit3

Issuerauthenticationissupported.Acardcan authenticateissuercryptogramusingeitherasecondcall toGENERATEACcommandorusingadedicated EXTERNALAUTHENTICATEcommand(seealso section5.3.13.2).

Bit2Reservedforfutureuse.

Bit1

CDAsupported.Theapplicationsupportsoffline combineddatacarddataauthentication(seesection 5.3.8.7).

5.3.7ReadApplicationData

OncetheapplicationselectionhasbeencompletedandtheAFLhasbeenprovidedtotheterminalapplication(seesection5.3.6.2),theterminalcanreadapplicationdata.Thedataaccessibletotheterminalcanbesplitacrossseveral applicationelementaryfiles(AEFs).

TheterminalapplicationiteratesoverAFLentries.Eachentrycontainsthe AEFShortFileIndicatortoberead,aswellastherangeofrecordstobe readfromtheAEF.TheterminalapplicationreadseachAEFissuingaREAD RECORDcommandforeachrecordintherelevantrangeforthefile.InresponsetotheREADRECORDcommandthecardreturnstheREADRECORD ResponseMessageTemplatewhichhastagvalueof70.Theterminalapplication parsesthesub-elementsofthetemplateandaddsthemtoacommonEMVdata objectsheapforfutureprocessing,discardinganyelementitisnotfamiliarwith inprocessbutkeepingoptionalelementsintheheap.

Oncethereadingprocessiscomplete,theterminalapplicationisabletoconfirmwhetherthecardprovidedallthemandatorydataobjectsTheEMVstandard mandatesthepresenceofApplicationExpiryDate(tag5F24),ApplicationPrimaryAccountNumber(PAN)(tag5A),andtwoDOLs—CardRiskManagement DataObjectList1(tag8C)andCardRiskManagementDataObjectList2(tag 8D).

Inadditiontothemandatoryobjectsthatmustalwaysbepresentinapplicationdata,theterminalalsoverifiesobjectsdependingontheprovidedAIP.Forinstance,ifthecardapplicationstatesitsupportscardholderverificationbysetting bit5intheAIPbyte1,thenapplicationdatamustalsocontaintheCardholder VerificationMethod(CVM)List(tag8E).Dependingonthestatedsupportfor offlineauthentication(SDA,DDA,combinedDDA),relevantdataobjectsmust alsobepresentintheapplicationdata.

5.3.8OfflineCardAuthentication

Priortotheintroductionofchiptechnology,cardauthenticationhardlyexisted. Ahologramembeddedinthecardwassupposedtobevalidatedbyallshopattendantsatallstores.Exceptforthehologramimage,therewerenoothermeansto confirmthecardgenuineness,andeventhatprotectivemeasurewasnotproperly enforcedbysalespersonnel.

Asforchiptechnology,theterminalisabletoauthenticatethecardcryptographicallyineveryEMVtransactionwhetheritiscontactorcontactlessor onlineorofflineone.Todoso,schemepublickeysareloadedintoeachEMV terminal.Thecarddeliversadigitalsignaturetotheterminalwhichthelatter verifieswithaschemepublickey.Certainly,schemeprivatekeysarenotusedto producecardsdirectlybutthereisakeychainoftrustbetweentheschemeand theissuerkeysallowingpropersignaturevalidation(seesection5.3.8.2).

Theprocessiscalled“offlinedataauthentication”andterminalscanchoseto skipthesteprelyingonissuercardauthenticationinstead(andthusperforming onlinecardauthentication).

Offlinecardauthenticationcanbeperformedusingoneofthefollowingstandardmethods(ifsupportedbythecardandtheterminal):

Staticdataauthentication(SDA). Astaticdataauthenticationvalueisprecalculatedbytheissuerandwrittenonthecard.Itisreadandvalidated bytheterminaluponeverytransaction,thusconfirmingtheauthenticity ofdatawritten(personalized)onthecardbytheissuer.Thattypeofauthenticationispotentiallyvulnerabletoreplayattacksbutrequiresless sophisticatedsoftwareandallowsforweakerhardwareonboththecard andtheterminal.

Dynamicdataauthentication(DDA). Adynamicdataauthentication(DDA) valueiscalculatedbythecarduponeachtransactionusingrandomdata fromboththecardandtheterminal.Successfuldynamicdataauthenticationmeansthatinadditiontothevalidoriginofthecardithasnotbeen modifiedafteritspersonalization.

Combineddataauthentication(CDA). Inessence,thatauthenticationmethod doesnotdifferfromtheDDAmethod,exceptthatthecardauthenticationvalueisgeneratedtogetherwiththeapplicationcryptogram(seealso section5.3.13.2).

Ifeitherthecarddoesnotsupporttheofflinedataauthentication(seesection5.3.6.1forbitsthatindicatethis)ortheterminalis“onlineonly”orthere isnomutuallysupportedofflinecarddataauthenticationmethod,theterminal skipstheentireofflineauthenticationstage,settingtherelevantbit(offlinedata authenticationwasnotperformed)intheTVR(seesection5.3.4).

TheterminalchoosestoprocessstaticdataauthenticationwhenitissupportedbothbythecardandtheterminalandneitherDDAnorcombineddata authenticationaremutuallysupported.Incaseofmultipleoptions,thestandard prescribescombineddataauthenticationasthepreferredmethod,followedby dynamicdataauthenticationandthenfollowedbystaticdataauthentication.

5.3.8.1CommonStepsofOfflineAuthentication

Roughlyallofflineauthenticationmethodsfollowthesameflowwiththefirst fewidenticalstepsforbothstaticanddynamicdataauthenticationmethods.

Theterminalstartsbyrecoveringthekeysitneedstoauthenticatethecard. Usingthekeys,theterminalcalculatesacryptographicsignatureindependently fromthecardandvalidatestheresults.Ifthesignature,presentorreturnedby thecard,isvalidatedbythevaluescalculatedbytheterminalindependently,the authenticationissuccessful.

Thegenericprocessofkeyrecoveryisdescribedinsection5.3.8.3,andthe genericprocessofsigneddatavalidationisdescribedinsection5.3.8.4.

AsthefirststepcommontoallauthenticationmethodswhentheissuerpublickeyisrecoveredusingdatareadfromcardduringtheReadApplicationData stageandbasedonpublicCAcertificatesprovidedbycardschemes(inthiscontextintheEMVstandard,theyarereferredtoas CertificationAuthorities or CAs).

PublicCAcertificatesarepre-loadedineachEMVterminalbytheacquirer whilethetheissuerpublickeyispersonalizedonthecardbythetheissuer.

Thatisthelaststepofstaticdataauthenticationandtheflowendsasthe terminalusestheissuerkeytodecipherstaticauthenticationsignaturefromthe cardandvalidateitusingdataelementsreadfromthecard.

Fordynamicdataauthenticationtheterminalusesasimilarmethodaswith theissuerpublickeytorecoverthecardpublickeyandthencontinueswith generatingdynamicauthenticationdatasendingthemtothecardusinganappropriatecommand,andvalidatingtheirresultusingthecardpublickeyanddata elementsreadfromthecard.

Uponcompletingtheauthenticationtheterminalsetsthe“Offlinedataauthenticationwasperformed”bitinTSIto1.

Ifoneoftheauthenticationmethodsfails,theterminalsetsbits“SDAfailed”, “DDAfailed”or“CDAfailed”oftheTVRto1.Otherwise,allthethreebitsare resettozero.

5.3.8.2KeyChainofTrust

Exchangingmessagessecurelyusingasymmetriccryptographyrequirespresharingofpublickeysbetweenparticipatingentities.Thatistrivialfortwoparties,butincaseofalargenumberofparticipantsinamessageexchange,the numberofrequiredkeyexchangesgrowsfast:inatheoreticalnetworkwithtwo issuersandtwoacquirersoneneedstoexchangefourpairofkeys,whichisa nuisance;ahundredparticipantsrequire2,500keyexchangeswhichissimply notfeasible.

Tomakeasymmetriccryptographyscalable,allpracticalasymmetricalgorithmssupportaformofdelegationoftrustinwhichanentitytrustedbymany participantsofmessageexchangescansignkeysthuswitnessingtheirvalidity. Considerthetreeofparticipantsin figure5.4

Toensurethateachmemberofthehierarchyexceptitsrootisabletovalidate adigitalsignatureofanyothermemberofthehierarchy,itissufficienttodistributethepublickeyorkeysofthetreerootalsoknownastheRootCertificate AuthorityorTrustedCertificateAuthority.

Forexample,allbanks(L1nodes)trustthescheme(rootnode)andexchange keyswithit.Inprinciple,banksdonotexchangekeyswitheachother.Ifsucha bankencountersamessagesignedbyanotherbank’skey,itcannotvalidatethe

Figure5.4:Keyhierarchy

signatureandconfirmthatitbelongstothecounterpartbank,butitcancheck thatthemessagewassignedbyakeythat,inturn,wassignedbythescheme. Thetransitiverelationshipisreferredtoasa keychainoftrust

Thatabilitytoovercometheproblemofscalecomesinespeciallyhandy withbillionsofcardsandhundredsofthousandsifnotmillionsofEMV-capable terminals.

Eachcardcommunicateswiththeterminalithasbeentappedonorinserted intowhilecryptographicallysigningexchangedmessages.Itisobviouslynot feasibletohaveallcardsandallterminalsexchangeanindividualpairofkeys. However,inthediagramabove,cardsandterminalsroughlycorrespondtoL2 nodes,banksareL1nodesandtheschemeistherootauthority.Therefore,approximately,thefollowingproceduretakesplaceincaseofprotectedEMVcards againstcounterfeits 1:

Theschemegeneratesitsrootkeypairandstorestheprivatekeyasavery closelyguardedsecretdistributingitspublickeythroughouttheentire network:toallbanksandespeciallyallterminalsthataimtoprocesscards ofthatparticularscheme.

Eachissuergeneratesakeypairitwouldliketouseforcardpersonalization,sendsitspublickeytobesignedbytheschemeandgetsitbackwith digitalsignatureoftheschemeandtherootauthorityofthehierarchy appliedtoit.

Eachcardpersonalizedbythatissuercontainsitsownkeywhich,inturn, issignedbytheissuer’sprivatekey.

1ThedescribedscenarioliststhefullsetofkeysusedforDynamicDataAuthentication(DDA).Static DataAuthentication(SDA)doesnotinvolvecard-specifickeys.

Whenthecardcommunicateswithaterminal,theterminalseekstoestablish trustwiththecard,orconfirmitsauthenticityotherwise.Theterminalhasthe schemepublickeydeployedinit.Itcannotdirectlyvalidatetheprivatekeyof thatparticularcard,butusingtheschemepublickey,itcanconfirmthatthecard wasissuedbyabankthatistrustedbythescheme.

Fullhierarchyofkeysthatcanbeusedbyanissuerisshownin figure5.5. Theexactusageandpurposeofthesekeysisdescribedlater.

Figure5.5:Scheme,issuerandICCkeyshierarchy

5.3.8.3PublicKeyRecovery

Underaforementionedscenarios,terminalshavetorecoverissuerpublickeys andICCpublickeys.Therecoveryalgorithmusedforbothtypesofkeysisvery similar:

1.Theterminalretrievesthekeycertificatefromthecard.The keycertificate isadatastructurethatincludespartofthekeyormorerarelythewhole keyencryptedwithaprivatekeytowhichtheterminalhasamatching publickey.

2.Iftheentirekeyistoolongtofitintothecertificate,theremainingbytes ofthekey(keyremainder)areprovidedbythecardinunencryptedform.

3.Theterminaldecryptsthecertificateusingthepublickeyithas.Theresult ofthedecryptionhastostartwithconstantdataheader(0x6A)anddata

trailer(0xBC)which,ifnotmatched,causetheterminaltoconsiderthe entireprocessofcardauthenticationasafailure.

4.Ifthedataheaderandthetrailerofthedecryptedcertificatearevalid,itis separatedintotwoparts.Thefirstpart,commonlydenotedasMR,isthe unencryptedcertificatecontainingsomeadditionaldataabouttheformat, owningentity(BINorPAN),expirydateand,mostimportantly,leftmost digitsofthepublickey.Thesecondpartorthelast20bytesofthevalue iscommonlydenotedasHandisthehashvaluefortherecoveredfull certificate.

5.TheterminalcombinesthedecryptedcertificatewiththeKeyRemainder, appliesaspecifiedhashfunctiontoitandcomparestheresultwithH. Iftheresultmatches,theterminalconsidersthekeyrecoverysuccessful, extractsthekeypartfromthecertificateandcombinesitwiththeclear-text keyremainderandthekeyexponentvaluestoobtainthefullkey.

6.Theterminalperformssuchadditionalvaliditychecksofthecertificateas itsexpirydate,BIN,etc.andifallarepassed,acceptsthekeyforfurther processing.

Asmentionedabove,cardschemesissuingrootkeypairsfunctionasCertificateAuthoritieswiththeEMVstandard.Thepairsarethenhandledthus:

Thepublickeysofcardschemesaredistributedpubliclyandareusually accessibleoncardschemewebsites.Theyarepreloadedintoterminals byrespectiveterminalnetworkoperatorsoracquirers.Eachcompliant terminalmustbeabletoholdanarrayofCArootkeysandeachcard applicationindicatestotheterminaltheindexofthekeyitrequiresto use,usingthe“CertificationAuthorityPublicKeyIndex”dataobject(tag 8F).

Privatekeysofcardschemesaresharedwithnoone.Issuerssubmittheir issuerpublickeystocardschemesandreceivesignedcertificatesback. Thenthecertificatesareusedtopersonalizetheissuers’cards.

NotethatthefullkeyrecoveryalgorithmisdescribedinmoredetailsinEMV Book2,SecurityandKeyManagement,inchaptersStaticDataAuthentication andtheDigitalSignatureSchemeGivingMessageRecoverysectionofSecurity MechanismsAnnex.Itisalsorepeatedtherefordynamicdataauthentication.

Inadditiontotheaforementionedkeys,thecardcancontain(andtheterminal mayhavetorecover)anICCPINenciphermentkey.Itisrecoveredusingissuer publickey.Fullhierarchyandorderofrecoveryofkeysthatcanbeusedwitha particularICCapplicationisshownin figure5.6.

5.3.8.4SignedDataValidation

Inalldatavalidationscenariostheterminalobtains—eitherbyreadingfromthe cardastaticvalueorbyreceivingaresponsetoacommand—adatafieldwith signeddataitneedstovalidatetheuseofapreviouslyrecoveredpublickey. Asaprerequisite,theterminalobtainsapublickeyitusesfordatavalidation. Thevalidationprocesshappensasfollows:

1.Theterminalcomputesthedatabytestringthatshouldbesignedandvalidated.Thatstepdiffersbetweenstatic,dynamicandcombineddataauthenticationmethods,seedetailsbelow,andthebytestringisfurtherreferredtoasa dataauthenticationinputvector

2.Theterminalobtainsthesigneddatastringfromthecard.Thestepalso differspermethod.

3.Asaresultofthetwostepsabove,theterminalhasastringofclear-text dataM,avectorofsigneddataSandapublickeyKinitsmemorythat shouldbeusedfordatavalidation.

4.Theterminalusesthepublickeytodecipherthesigneddata.Theresult shouldcontainthedataheader(0x6A)andthedatatrailer(0xBC).Ifthe actualresultdiffers,thevalidationisconsideredasfailed.

5.Theterminalstripstheheaderandthetrailerandthenreferstothelast20 bytesofthedataashashcodeH.Theterminalconcatenatesalldeciphered dataexceptthehashandthesentinelbyteswiththedataauthentication

inputvectoritpreparedatstep1andusesanappropriatehashalgorithm tocalculateitshashvalue.

6.ThenitcomparesthehashtotherecoveredHvalue.Ifthevaluesmatch, thesigneddatahavebeenvalidatedsuccessfully.

5.3.8.5StaticDataAuthentication(SDA)

AsmentionedinthesectionontheApplicationFileLocator,eachentryinAFL mentionsashortfileidentifier,thefirstandthelastrecordsinafilewhichareto bereadbytheterminalaswellasthelastrecordofthefilethatisrelevantfor offlineauthentication.

Usually,theterminalcombinesalltherecordsthusprescribedintothedata authenticationinputvectorwhileotherreadingapplicationdata,forefficiency.

Inaddition,iftheoptional“StaticDataAuthenticationTagList”(tag9F4A) ispresent,theterminalappendstheAIPtothedataauthenticationinputvector, astheoptionaltagisonlyallowedtocontainthetagvalueforAIP2

Theterminalneedstorecovertheissuerkeyfromthecardfollowingthesteps describedinsection5.3.8.3whenitusesacardschemepublickey(identifiedby “CertificationAuthorityPublicKeyIndex”,tag8F)torecovertheissuerkey from“IssuerPublicKeyCertificate”(tag90),“IssuerPublicKeyRemainder” (tag92)and“IssuerPublicKeyExponent”(tag9F32).

ThentheterminalperformssigneddatavalidationasdescribedinSigned DataValidation,withstaticrecords(andoptionalAIP)itconcatenatedandusing theissuerpublickeyasthevalidationkey.Dataobject“SignedStaticApplication Data”(tag93)containsthesigneddataforvalidation,andifthecardsupports SDA,itismandatoryfortheobjecttobepresentonthecard.

5.3.8.6DynamicDataAuthentication(DDA)

DynamicDataAuthentication(DDA)greatlyimprovesdataexchangesecurity byintroducing,asthenameimplies,dynamicelementstotheauthenticationprocess.Itputsadditionaldemandonthecomputationalpowerofboththeterminalandthecardaswellasintroducesanadditionalstepinthetransactionflow slightlyslowingitduetoacommunicationoverhead.

ThedataauthenticationinputvectorforDDAisdefinedbytheDynamicData AuthenticationDataObjectList(DDOL)(seesection5.3.3)providedbythecard indataelement9F49.Iftheelementisnotpresent,theterminalisallowedto reverttoanacquirer-defineddefaultDDOL.

DDAdiffersfromSDAinseveralaspects.

First,theDDOLiscomposedbytheterminaldynamicallyandcancontainmultipletransaction-specificdetails.TheEMVstandardalsorequiresthat

2

TheolderversionofEMVspecificationdidnotrequireAIPinclusioninstaticdataforauthentication, andtheoptionaltaghasbeenintroducedtoallowsimultaneoussupportofbothitsnewerandolderflavors.

“UnpredictableNumber”(tag9F37)shouldbealwayspresentinanyDDOL,regardlessofwhetheritisprovidedbythecardorusedbytheterminalbydefault. The“UnpredictableNumber”isdefinedas“thevaluetoprovidevariabilityand uniquenesstothegenerationofacryptogram”andisusuallyarandomnumber generatedbytheterminalinamannerindependentofothertransactiondetails.

Second,tovalidatethesigneddynamicauthenticationdata,theterminaluses theICCpublickeyandnottheissuerpublickey.ToobtaintheICCpublickeythe terminalfirstusesacardschemepublickeytorecovertheissuerkeyasdescribed insection5.3.8.3andthenusestheissuerpublickeytorecoverICCkey.

Finally,ratherthanreferringtoastaticvaluealreadyreadbytheterminal duringtheReadApplicationDatastageofthetransaction,thesignedvalueis obtainedfromthecardusingaspecialcommandcalledINTERNALAUTHENTICATE.Inadditiontotheunpredictablenumberprovidedbyterminal,thecard alsogeneratesandreturnsan“ICCDynamicData”(tag9F4C)valuedefinedas “Time-variantnumbergeneratedbytheICC”andcanbeeitherasimplecounter incrementingoneachDDAortransactionattemptorarandomnumber.

TheDynamicDataAuthenticationflowstepsareperformedasfollows:

1.Theterminalusesaproceduredescribedinsection5.3.8.3toreconstruct theissuerpublickeyfromthe“IssuerPublicKeyCertificate”(tag90),“IssuerPublicKeyRemainder”(tag92)and“IssuerPublicKeyExponent” (tag9F32)usingacardschemepublickeyidentifiedby“CertificationAuthorityPublicKeyIndex”(tag8F).

2.TheterminalrepeatsthesameproceduretoreconstructtheICCkeyfrom the“ICCPublicKeyCertificate”(tag9F46),“ICCPublicKeyRemainder” (tag9F48)and“ICCPublicKeyExponent”(tag9F47),usingtheobtained issuerpublickeyinstep1.

3.TheterminalpreparesadataauthenticationinputvectoraccordingtoeitherICC-providedDDOLoracquirerdefaultsetintheterminal.Along thewaytheterminalalsogeneratesarandomnumber(theUnpredictable Number)andincludesitinthedatastring.

4.TheterminalissuesanINTERNALAUTHENTICATEcommandtocard. Thecommand’s P1 and P2 registersaresetto0,anditsdataarethedata sequenceprepared,basedontheDDOLinuse.Inresponsethecardsends backeither“ResponseMessageTemplateFormat1”(tag80)or“Response MessageTemplateFormat2”(tag77).Format1onlycontainsthesigned dynamicapplicationdatawhereasformat2maycontainadditionalelements.

5.TheterminalusestheICCpublickeytovalidatethesigneddata,asdescribedinsection5.3.8.4.

5.3.8.7CombinedDataAuthentication(CDA)

Combineddataauthentication(CDA)optimizesthetransactionflowofdynamicdataauthenticationforcaseswhenthecard’scomputationalpowerishigh enoughandtheoverheadofexchangingcommandswiththeterminalbecomesa bottleneck.DuringCDAthereisnoseparateexchangeofcommandsforthesole purposeofofflinecarddataauthentication.

Inotherwords,CDAis(almost)asfastasSDAandassecureasDDA. Insteadofmanagingaseparatelistofdataelementsandusingadedicated command,thecardusesthedataalreadyprovidedbytheterminalduringthe “GenerateApplicationCryptogram”step(seesection5.3.13).Itcalculatesthe signatureforthedataauthenticationinputvectorcomposedofPDOL,CDOL1 and/orCDOL2dataobjectlistsaswellasthetag,lengthsandvaluesofelementstotherelevantcommand.ForCDAtowork,theissuermustinclude“UnpredictableNumber”inbothCDOLs,thusmakingsuretheterminalisableto generateandsenditoff.

Besidestheaforementioneddifferences,theCDAflowissimilartoDDAone:

1.Theterminalusestheproceduredescribedinsection5.3.8.3toreconstruct theissuerpublickeyfromthe“IssuerPublicKeyCertificate”(tag90), “IssuerPublicKeyRemainder”(tag92)and“IssuerPublicKeyExponent” (tag9F32)usingacardschemepublickeyidentifiedbythe“Certification AuthorityPublicKeyIndex”(tag8F).

2.TheterminalrepeatsthesameproceduretoreconstructtheICCkeyfrom the“ICCPublicKeyCertificate”(tag9F46),“ICCPublicKeyRemainder” (tag9F48)and“ICCPublicKeyExponent”(tag9F47)usingtheissuer publickeyobtainedatstep1.

3.DependingonthetransactionflowduringthefirstorsecondGENERATE ACcommandtheterminalsetsabitinthecommand’sP1parameterasking theICCtoperformCDA.

4.Theterminalusestheinputitsentforthecommand(PDOLandthecorrespondingCDOL)and,unlikeotherdataauthenticationmethods,thetag, lengthsandvaluesofICCresponsedatatotheGENERATEACcommand togeneratethedataauthenticationinputvector.

5.TheterminalusestheICCpublickeytovalidatethesigneddataasdescribedinsection5.3.8.4.

ItisworthnotingthatintheEMVContactlessworld,thereisanotionof fast DDA or fDDA.Thatofflinecardauthenticationmethodalgorithmisidenticalto thatofCDA.However,duetosomedifferencesinthetransactionflow,thePOS usuallyreadsthedataitneedstovalidateafteritreceivesthesigneddatavalue andnotpriortoit.

5.3.9ProcessingRestrictions

DuringtheReadApplicationDatastep,theterminalreceivescertaindataregardingthecardapplicationusedtodeterminewhethertheapplicationisofcorrect version,canbeusedforthattypeoftransaction(referredtoas ApplicationUsage Control),isalreadyeffectiveandhasnotyetexpired.

5.3.9.1ApplicationVersionNumber

Todeterminetheapplicationversion,theterminalcheckswhetherthecardapplicationprovidedthedataelement“ApplicationVersionNumber”(tag9F08). Ifthenumberisnotpresentormatchestheonefoundintheterminal,theapplicationsarecompatibleandthetransactioncontinues.Iftheversionnumber asprovidedbythecarddiffersfromtheoneintheterminal,theversioncheck failsandtheterminalsetstheappropriatebit(“ICCandterminalhavedifferent applicationversions”)intheTVR.

5.3.9.2ApplicationUsageControl

Acardapplicationcancontainan“ApplicationUsageControl”(tag9F07)data elementhavingthelengthof2bytes.Itsbitscorrespondtovariousscenariosfor applicationusagesuchas“validfordomesticcashtransactions”or“validfor internationalservices”.Italsocontains“validatATMs”and“validatterminals otherthanATMs”flags.

Theterminalstartstheusagecontrolcheckbyinspectingthelattertwoflags anddeterminingwhetherthetransactioncanproceedbasedontheterminaltype. Ifthe“IssuerCountryCode”dataelement(tags5F28,5F55or5F56indifferent formats)ispresentintheapplicationdata,theterminalbasedonitsownlocation datadetermineswhetherthetransactionisinternationalordomestic,and,finally, checksthetransactiontype.

Forinstance,considerPOSlocatedatastoreinGermanyandacardissued inIcelandandacardholderattemptingtopurchasegoodswithoutacashback amount.Theterminalfirstchecksthatthecardapplicationisvalidfornon-ATM terminals.Iftheflagisset,theterminalcomparestheissueranditsowncountry codedeterminingthetransactionasaninternationaloneandnotdomesticone. Thentoallowthetransactionitcheckswhetheratleastoneof“Validforinternationalgoods”or“Validforinternationalservices”bitsissetintheApplication UsageControl.

Incasetheusageisnotallowedforthecardapplication,theterminalsetsthe appropriatebit(“Requestedservicenotallowedforcardproduct”)intheTVR.

5.3.9.3ApplicationEffectiveandExpirationDate

Ifthecarddatacontainthe“ApplicationEffectiveDate”(tag5F25),theterminalcheckswhetheritislessorequaltothecurrentdate.Ifthereisafuture

applicationeffectivedate,theterminaldoesnotallowthetransactiontoproceed, setting“Applicationnotyeteffective”bitintheTVRto1.Ifthereisnoapplicationeffectivedateonthecard,theapplicationisconsideredeffective.

Aftercheckingtheeffectivedate,theterminalcheckswhetherthe“ApplicationExpirationDate”(tag5F24)isnotexceeded(i.e.,islaterthanthecurrent dateororequaltoit).Ifitisexceeded,thecheckhasfailedandtheappropriate bit(“Expiredapplication”)issetintheTVR.

5.3.10CardholderVerification

Thecardapplicationusuallycontainsa“CardholderVerificationMethodList” (CVMList)(tag8E)dataelement,definingtherulesaccordingtowhichthe terminalshouldselectthecardverificationmethodormethodstouse.Thedata elementcontainstwoamountfieldsreferredtoasXandYandalistofthecardholderverificationrules(CVRs),whichisavariable-lengtharrayof2-bytevalues.

5.3.10.1AmountFields

Thefirst8bytesoftheCVMListdataelementcontaintwoamountfields.Each amountfieldisencodedinbinaryformatwithimplicitdecimalpoint.Each amountisexpressedin“ApplicationCurrencyCode”(tag9F42)storedonthe cardandretrievedduringtheReadApplicationDatastep.

Forexample,iftheapplicationcurrencyisEuro(978)thenthevalueof 0x07BAforthefirstamountfieldcorrespondstotheamountof19.78EUR.

Specificcardholderverificationrulesrefertothefirstandsecondamountas XandYtodefinetheconditionsunderwhichasaidruleisapplicable.

5.3.10.2CardholderVerificationRules

Eachofthecardholderverificationrulesconsistsof2bytes,withthefirstone specifyingtheCVMtobeused,andthesecondonespecifyingthecondition underwhichtheverificationmethodistobeapplied.Thefirstbyteiscalled CardholderVerificationMethodcode(CVMcode)andthesecondbyteiscalled CardholderVerificationMethodConditioncode(CVMConditioncode).

Theleftmostbit(8)oftheCVMcodeisreservedforfutureuse.

Bit7oftheCVMcode,ifsettozero,indicatesthattheterminalshouldend thecardholderverificationstageiftheCVMfails.Ifthebitissetto1,theterminal cancontinuetothenextCVMonthelistifthemethodfailed.

Bits6to1oftheCVMcoderepresentthemethodsupposedtobeapplied. Theyarelistedwiththecorrespondingbitvaluesbelow:

FailedCVMprocessing(000000). ThemethodisusedtoforceCVMfailurein theterminal.Forexample,itcanbetheterminatingmemberofaCVM

listtomakesurethatthecardholderverificationisconsideredfailedifno othermatchingCVrulewaspreviouslyfound.

CleartextofflinePIN(000001). ThePINistransmittedbytheterminaltothe cardunencryptedforofflinevalidation.

OnlinePIN(000010). PINasenteredbythecardholderistransmittedtothe issuerforvalidationintheformofanencryptedPINblock(EPB).

CleartextofflinePINandsignature(000011). ThatisacombinationCVMof clear-textofflinePINandsignature.

EncipheredofflinePIN(000100). ThePINisencipheredbytheterminaland thensenttothecardforofflinevalidation.

EncipheredofflinePINandsignature(00101). ThatisacombinationCVM oftheencipheredofflinePINandsignature.

Signature(011110). AslipisprintedbythePOS,thecardholderhastosign itandtheshopattendantisexpectedtocompareittothesignatureon thecardsignaturestrip.AsofApril2018,mostmajorschemesnolonger requirethatshopsacceptingEMVcardsstorethesignatureslips.

NoCVM(011111). Noverificationofthecardholderisperformed.

TheseCVMsarealsodescribedinsection2.7.

Besidesthestandardcodesmentioned,theEMVspecificationreservesranges 000110to011101forfutureuseandallocatesranges100000to101111and 110000to111110forusebyindividualschemesandindividualissuers,correspondingly.Thevalueof111111hasaspecialmeaningfortheCVMresultsdata element(seesection5.3.10.3).

TheCVMconditioncodesincludethefollowingkeyvalues:

Always(0x00). IndicatesthattheCVMshouldbealwaysattempted.

IfterminalsupportstheCVM(0x03). IndicatesthattheCVMshouldonlybe attemptedifsupportedbytheterminal(or,inotherwords,itisacceptabletoskipthismethodiftheterminaldoesnotsupportit,e.g.,isunattended/hasnoprinterforasignatureslip).

Ifunattendedcash/Ifmanualcash/Ifpurchasewithcashback (0x01/0x04/0x05) Applicableinthecorrespondingcash-relatedscenario.

Ifnocashinvolved(0x02). Inthestandardthevalueisofficiallyreferredtoas “notunattendedcashandnotmanualcashandnotpurchasewithcashback”.Inpractice,itappliestothemostwidespreadtypeofcard-present transaction—thebasicPOSpurchase.

Ifunder/overvalue(0x06/0x07/0x08/0x09). Theruleisapplicableifthetransactionisinapplicationtransactioncurrency(transactioncurrencycode equalsapplicationcurrencycode)andisunderXvalue(0x06),overX value(0x07),underYvalue(0x08)oroverYvalue(0x09).

Thevalueranges0xAto0x7FarereservedforfutureusebytheEMVstandardwhilerange0x80to0xFFisallocatedforproprietaryusebypayment schemes.

Uponthecompletionofcardholderverification,theterminalshouldsetbit “Cardholderverificationwasperformed”to1intheTSI.IftheCVRlistisnot presentinthecardapplicationdataordoesnotcontainanyrulesthebitissetto zero.

Inaddition,theterminalperformsspecialhandlingofaconditionwhenPIN entryisrequestedbutPINpadisnotattachedorfunctionalbysettingbit“PIN entryrequiredandPINpadnotpresentornotworking”oftheTVRto1.

5.3.10.3CVMResults

Theresultsofthelastexecutedcardholderverificationarestoredindataelement “CardholderVerificationMethod(CVM)Results”(tag9F34).Thedataelement containsthreebytes:theCVMCodeoftheverificationmethodthatwasperformed,theCVMConditionCodethatwasfulfilledandtheCVMResultbyte carryingtheCVMstatus:0forunknown(suchassignature),1forfailedand2 forsuccessfulCVM.

IfnoactualCVMwasperformed,theCVMcodeissetto0x3F(bitvalue 00111111,withlower6bitscorrespondingtothereservedvalueofsix1bits). Byte2andbyte3oftheCVMResultsdataelementaresetto0(“alwaysattempted”and“failed”),correspondingly.

5.3.10.4ExampleofaCVMList

Forthesakeoftheexample,letusassumethattheapplicationcurrencyisthe euro.

ConsidertheCVMlistin figure5.7,andlet’sreviewitaccordingtotheformat mentionedabove.

Thefirst4bytesare“amountX”and“amountY”,whichare0x4E20and 0xC350,or20000and50000decimal,andcorrespondtoamountsof200and 500Euro.

TheCVMrulelistcontainsfiverules.

Rule1inbytes5and6containsthevalueof0x0201.Byte1istheCVM code,binary00000010.The0ofbit7meanstheterminalcannotproceedtothe nextCVMruleifthatonefails,andvalueof000010correspondstoonlinePIN. Byte2value,0x01,indicatesthattheruleappliesforunattendedcash(inother words,ATM).

Figure5.7:ExampleofaCVMlist

Rule2inbytes7and8containthevalueof0x4502.TheCVMcodeisbinary 01000101,correspondingto“encipheredofflinePINandsignature”andbit7 meanstheterminalcanproceedtothenextCVMruleifthatonefails.TheCVM condition,0x02,meansthatisaPOStransaction.

Rule3inbytes9and10containthevalueof0x4406.TheCVMcodebinary valueis01000100,correspondingto“encipheredofflinePIN”.Bit7allowsthe terminaltoattemptthenextCVMifthatoneisnotsupported.TheCVMcondition,0x06,specifiesthattheruleappliesfortransactionsundervalueofXor below200Euro.

Rule4inbytes11and12containthevalueof0x4207.TheCVMcodebinary valueis01000010,correspondingto“onlinePIN”andallowingtoskiptothe nextCVMruleiffailed,andtheCVMconditionmeans“overvalueofX”or above200Euro.

Finally,rule5inbytes13and14contain0x0000.Thatmeans“failedCVM processing”,noskippingtothenextCVMandisapplicable“always”.

Letusconsiderseveralpossiblescenariosunderwhichthecardcanbeused.

Scenario1

AssumethatthecardisusedtowithdrawfundsinanATM.Rule 1CVMconditioncodeappliesforunattendedcashandinthiscaseis attemptedbytheterminal.

Scenario2

AssumethatthecardisusedtowithdrawfundsinanATMbutthis timetheonlinePINverificationfails:eitherthePINpadisnotfunctional orconnectiontoacardschemenetworkisnotavailable.Theterminalis notallowedtoproceedtothenextrule,anditconsidersCVMfailed.

Scenario3

Assumethatthecardisusedforapurchaseof150euroatastore. Theterminalskipsrule1,sincethetransactiondoesnotinvolveaformof cashwithdrawalandproceedstorule2.Theterminalattemptstovalidate theencipheredofflinePINandcollectthecardholder’ssignature.

Scenario4

Assumethatthecardisusedforapurchaseof150euroatastorebut thePOShasnoprinterattached.Theterminalskipsrule1sinceitisnot applicableforretailstores.Itattemptsrule2,butseeingthereisnoprinter

considersitfailed.Bit7oftherule’sbyte1allowstheterminaltoproceed tothenextruleorrule3.Theruleisapplicableforanytransactionofless thanamountX,i.e.,200euro,andisthereforeapplicablehere.Underthe rule,theterminalperformstheonlinePINvalidationwithoutcapturingthe signature.

Scenario5 Assumethatthecardisusedforapurchaseof250euroatastorebut thePOShasnoprinterattached.Theterminalskipsrule1sinceitisnot applicableforretailstores.Itattemptsrule2,butseeingthereisnoprinter considersitfailed.Bit7oftherule’sbyte1allowstheterminaltoproceed torule3,butsinceitsCVMconditionisfortransactionsunder200euro, itisskippedasnotapplicableandtheterminalconsidersrule4.Rule4is applicablefortransactionsoveramountXand,therefore,inthiscase,it prescribesonlinePINvalidation,whichthePOSistoattempt.

Scenario6 AssumingthatPINvalidationfailsinscenario4orthereisnoconnectivityinscenario5,theterminalreachesrule5whichisalwaysapplicableandalwaysfails.

Torephrasetheabovelogic,thesetofrules:

PrescribesonlinePINandonlinePINonlyforanyATMcashwithdrawal. AlwaysattemptstocollectthesignatureandvalidateofflinePINforany in-storepurchase.

Ifanin-storeterminaldoesnotsupportthesignaturecollection,therules allowencipheredofflinePINvalidationfortransactionsunder200euro andforceonlinePINvalidationfortransactionsover200euro.Notethat theruleisalsoappliedifthetransactionisamanualcashwithdrawalor acashbackpurchase.

Iftheabovevalidationmethodsdonotwork,theCVMfails.

5.3.10.5OfflinePINVerification

DuringtheofflinePINverificationprocesstheterminalapplicationandthecard applicationinteracttovalidatethePINwithoutinvolvingtheissuer.Asalready mentionedabove,theofflinePINcanbevalidatedinplaintextorenciphered mode.Themodereferstocommunicationbetweentheterminalandthecard onlyasnoPINdetailsaresentelsewhere.

ThecardkeepstrackofthenumberofPINattemptsmade.

TherearethreewaysforofflinePINverificationCVMtofail:

Theterminaldoesnotsupportiteitherpermanently(notimplementedor noPINpad)ortemporarily(PINpadnotworkingormissing).Inthis

casetheterminalsets“PINentryrequiredandPINpadnotpresentornot working”bitoftheTVRto1.

AllattemptstoverifythePINhavefailed,thecardcouldnotdecryptthe encipheredPINordecidedtoblockthePINuponthefirstentry.Inthis case,theterminalsets“PINtrylimitexceeded”bitoftheTVRto1.

Merchant/customerdecidedtobypassPINentry.TheconditionwasdesignatedbythestandardtobeusedfornewcardholdersandduringtransitionstoPINCVMincaseswhenthecardholderrealizestheyhaveforgottenordonotknowthePIN.Inthiscase,theterminalsets“PINentry required,PINpadpresent,butPINwasnotentered”bitoftheTVRto1, thusinformingtheissuerthatthePINentrywasvoluntarilybypassed.

Overview

ToverifythetypeofPINverificationasthefirststeptheterminalcanretrievethe numberofPINattemptsremaining.ThatcanbedonebyissuingaGETDATA commandtothecardwithP1P2setto9F17(dataelement“PersonalIdentificationNumber(PIN)TryCounter”).Ifthevaluereturnedbythecardapplicationis zero,PINattemptsareexhaustedandtheCVMhasfailed.Thestepisnotmandatorysince,asitcanbeseenbelow,theVERIFYcommandisabletoreturnthe numberofremainingPINtriesinitsstatuswords.

Otherwise,theterminalneedstoverifythePIN.PINverificationisdoneusingtheVERIFYcommand.TheVERIFYcommandisissuedwith P1 setto00 andwith P2 settoeither0x80forplaintextor0x88forencipheredPIN3.The commandcanprovidethreeoptionalresponses:

Thecardapplicationreturnsasuccessresponsecode(SW1/SW2 equalto 9000).ThatmeansthePINwasverifiedandtheEMVtransactioncan proceed.

Thecardapplicationreturnsacheckingerror(SW1/SW2 of6983or6984).

ThatmeansthecardapplicationblockedthePINatthefirsttryorfailed todecipherthePINblock.Ineithercase,thereisnopointtoretrythePIN validationandthePINvalidationshouldbeconsideredafailure.

Thecardapplicationreturnsawarningerror(SW1 equalto63).That meansaparticularPINverificationattempthasfailed.Inthiscase, SW2 is intheformofCn,wherenindicatesthenumberofPINattemptsremaining(C2for2attempts,C1for1attempt,C0fornoattemptsremaining).

IfthePINistobeenciphered,theterminalissuesaGETCHALLENGEcommandtoobtainnecessarydatafortheencipherment.

3AlthoughtheEMVstandardmentionsvalueofP2 = 00accordingtoISO/IEC7816-4standard,itis notusedinEMVapplications.

CleartextOfflinePINVerification

ToperformthecleartextofflinePINverificationtheterminalpromptsthecardholderforthePINvalueandthenissuesaVERIFYcommandtothecardwith P2 valuesetto0x80.ThePINvalueenteredispackagedintoaISO-9564Format 2PINblock(seesection13.1fordescriptionofPINblockformats).

EncipheredOfflinePINVerification

ThePINisencipheredwithapublickeywhichshouldbepersonalizedonthe card.Furthermore,toavoidreplayattackstheterminalusesanunpredictable numberprovidedbythecardaspartoftheencipheredPINenvelope.

Torecoverthekeytheterminalfirstchecksthepresenceof“IntegratedCircuit Card(ICC)PINEnciphermentPublicKeyCertificate”(tag9F2D),“Integrated CircuitCard(ICC)PINEnciphermentPublicKeyExponent”(tag9F2E)and “IntegratedCircuitCard(ICC)PINEnciphermentPublicKeyRemainder”(tag 9F2F)elements.

Ifpresent,theterminalappliesthealgorithmdescribedinsections5.3.8.3and 5.3.8.6torecovertheissuerpublickeyandthenutilizestheissuerpublickeyto recovertheICCPINenciphermentpublickeyusedtoencipherthePINblock.

Iftheelementsarenotpresentinthecardapplicationdata,theterminal checkswhetherelements“ICCPublicKeyCertificate”(tag9F46),“ICCPublicKeyRemainder”(tag9F48)and“ICCPublicKeyExponent”(tag9F47)are presentinthecardapplicationdata.Iftheyareavailable,theterminalrecovers theICCpublickeyandusesittoencipherthePINblockinsteadofadedicated ICCPINenciphermentkey.

InadditiontotherecoveryofthePINenciphermentkey,theterminalissues aGETCHALLENGEcommandtothecard.Thecommandhasnocommand data.Thecardrespondswitharandomsequenceof8bytes,dataelement“UnpredictableNumber”(tag9F37),whichtheterminal,inturn,usesasdescribed below.ToprepareinputdatafortheencipheredPIN,theterminalappends:

Dataheader(0x7F)

PINblockaccordingtoISO9564format2.

ICCunpredictablenumberasreturnedbytheGETCHALLENGEcommand.

Randompaddingtothefulllengthofthepublickeyusedforencipherment.

TheresultisencryptedusingeithertheICCPINEnciphermentPublickey orICCPublickeydependingonwhethertheformerisorisnotpresentinthe applicationdata.TheencryptedoutcomeissenttothecardinVERIFYcommand withits P2 valuesetto0x88.

5.3.10.6OnlinePINVerification

ForonlinePINverificationtheterminalmustcapturethePINenteredbythe cardholderandensureitistransmittedsecurelytothecardissuer.OnlinePIN verification,ifsupported,canfailintwocases:

ThePINpadisnotpresentormalfunctioning.Inthiscasetheterminal sets“PINentryrequiredandPINpadnotpresentornotworking”bitof theTVRto1.

PINentryisbypassed.Inthiscasethebit“PINentryrequiredandthe PINpadpresentbutthePINwasnotentered”oftheTVRissetto1.

TheEMVstandarddoesnotmandateaparticularformatinwhichtheterminal cantransmitthePINtotheterminalmanagementsystem.However,oncethe transactionreachesaschemenetwork,thePINblockmustbegeneratedaccordingtotheformats0,1or4(seesection13.1)andencryptedwithaZonePINKey (seesection8.3.2).

5.3.11TerminalRiskManagement

5.3.11.1OfflineAuthorizationandTerminalRiskManagement

AtthetimewhentheEMVtechnologywasinceptedandrolledoutanelectronic terminalwasnotnecessarilyabletomaintainapermanentconnectiontothenetworkandauthorizeeachtransactiononline.Nowadays,whenterminalmanufacturersoffervariouswirelessconnectivityoptionsasastandardpackage,offline authorizationisbecominganichefeatureforspecificapplications.

Offlineauthorizationisafeatureallowingacardtomakedecisionsontransactionswithoutconsultingtheissuerbasedonsomerules(implementedasaset ofthresholdsandcounters).Acardcandecidetoeitherauthorizethetransaction offlineatthespot,forcetheterminaltogoonlineinfrontoftheissuer,orinstructtheterminaltoattemptanonlineauthorizationandiftheconnectionisnot available,approvethetransactionofflineanyway.

IntheworldofEMV,“Terminalriskmanagement”refersasetofchecksa terminalshouldperformtoselectivelyforceonlineauthorizationofaparticular EMVtransaction.Technically,theterminalgatherstheresultsofriskchecksin TVRbitsandthenappliesbitmaskstodeterminethewaytohandlethetransactionfurtherbasedontheacquirerandissuer’spreferences.Seesection5.3.12for adetailedprocessdescription.

Therearethreemajortypesofriskchecks.Theyare:the floorlimitchecking whentheterminalgoesonlinefortransactionsoveraparticularaccumulated limit, randomtransactionselection whentheterminalreliesonarandomnumbertoauthorizeaparticulartransactiononline,and velocitychecking whenthe terminalchecksasoftandahardlimitfornumberofofflinetransactionsthatare allowedsinceanonlinecardauthorization.

Thefloorlimitandrandomtransactionselectionparametersaresetbythe acquireraccordingtothecardschemerules.Thevelocitycheckingparameters aredefinedbytheissuer.

5.3.11.2FloorLimit

Thefloorlimitvaluereferstoaminimumtransactionamountabovewhichany transactionmustbeauthorizedonlineordeclinedbytheterminal.Thefloorlimit istypicallysetbyaspecificacquirerformerchantswithinoveralllimitsprescribedbyrelevantcardschemes.Theacquirercanelecttolowerthefloorlimit tozeroforaparticularterminalsolutionthusflaggingallthetransactionstobe authorizedonlineordeclined.

TheEMVstandardrecommendsbutnotmandatesmaintainingalogfileon theterminaltoavoid“splitsales”,abehaviortypewhenmultipletransactionsjust underalimitaremadetocircumventthethreshold.Iftheterminalmanagessuch alog,itshouldaddthelatestvaluefromthelogtothecurrenttransactionamount inordertodeterminewhetherthesumofthetransactionisaboveorbelowthe floorlimit.

Toillustratethatconsiderthefollowingexample.Ifthefloorlimitis25euros andtherequestedamountis15euros,thetransactionisbelowthefloorlimit. However,iftherehasbeenarecenttransactionof15eurosrecordedinthelog, theterminalshallconsidertheamountof30euroswithregardtothefloorlimit.

Ifaparticulartransactionamountorthesumofamountsexceedthefloor limit,theterminalsetsthe“Transactionexceedsfloorlimit”bitoftheTVRto1 which,inturn,mayforcethetransactiononlineauthorization.

5.3.11.3RandomTransactionSelection

Therandomtransactionselectionprocessperformsarandomselectionoftransactionsunderacertaintransactionamount,called“ThresholdValueforBiased RandomSelection”(hereinreferredtoasBRSthreshold).Acertainpercentage oftransactionswithamountsnotexceedingthethresholdvaluearechosenfor onlineauthorization.ForamountsexceedingtheBRSthresholdvaluethepercentagegoesuplinearlyupuntilthefloorlimit(overwhichitis,naturally,100% asalltransactionsareauthorizedonline).

Todeterminewhetheratransactionshouldbeflaggedtobesentonlinethe terminalgeneratesarandomnumberbetween1and99.Thentheterminalcomparesittothetargetpercentageforthetransactionamountandifthenumber doesnotexceedthetargetpercentage,decidestoauthorizethetransactiononline.Inparticular,thatmeansthatthehigherthetargetpercentageis,thehigher theproportionoftransactionstobeauthorizedonlineis.

FortransactionsofamountsnotexceedingtheBRSthreshold,therandom selectionaccordingtoaparametercalled“TargetPercentagetobeUsedforRandomSelection”isperformed.FortransactionsexceedingtheBRSthreshold,a

biasuptothevalueof“MaximumTargetPercentagetobeUsedforBiasedRandomSelection”isadded.

LetBbetheBRSthreshold,Xthetransactionamount,Fthefloorlimit,Tthe targetpercentageforrandomselectionandMthemaximumtargetpercentagefor biasedselection.ToperformtherandomselectiontheterminalhastocalculateE ortheeffectivetargetpercentage.

Figure5.8:Effectivetargetpercentage

Intheseterms,thefollowingformulasdefinethevaluesforeffectivetarget percentage:

If X < B,thenE = T(thevalueistoolowandthepercentageisfixed)

If F > X >= B,then E = T + (X B) (F B) × (M T ) (linearbiasisaddedto thefixedpercentage)

If X >= F,thenE = 100(thevalueisoverthefloorlimitandalltransactionsmustgoonline)

Thisdependencyisillustratedin figure5.8.

5.3.11.4VelocityChecking

Velocitycheckingisperformedintermsofthenumberoftransactionssincethe lastonlineauthorization.Itsparametersarepersonalizedonthecardbytheissuer insuchdataobjectsas“LowerConsecutiveOfflineLimit”(tag9F14)and“Upper ConsecutiveOfflineLimit”(tag9F23).

Iftheseelementsarepresent,theterminalissuesGETDATAcommandsto thecardrequestingthevaluesof“ApplicationTransactionCounter(ATC)”(tag 9F36)and“LastOnlineApplicationTransactionCounter(ATC)Register”(tag 9F13).ATCcountstransactionsperformedbythecardapplication,andtheregistercontainstheATCvalueofthelasttransactionauthorizedonline.

TheterminalsubtractstheregistervaluefromtheATCandcomparesittothe lowerandupperconsecutiveofflinelimits.Ifthedifferenceexceedsthelower consecutivelimit,theterminalsetstheTVRbit“Lowerconsecutiveofflinelimit exceeded”to1.Ifthedifferenceexceedstheupperconsecutivelimit,theterminal setstheTVRbit“Upperconsecutiveofflinelimitexceeded”to1.Finally,ifthe ATCisequaltozero,theterminalsetstheTVRbit“Newcard”to1.

5.3.12TerminalActionAnalysis

Uponcompletingtheprevioussteps,theterminalmakesapreliminarydecision aboutthefateoftheparticulartransaction.Theterminalcandecidetodecline itoffline,authorizeitofflineorattemptanonlineauthorization.Thedecisionis madebasedonthecombinationofrulessetbytheissuer,therulessetbythe acquirerandthevaluesinTVRaggregatedaspartofthetransaction’sprevious steps.

Therulesarecalled actioncodes andarestoredintwogroupsofthreeregisterseach.Thereareissueractioncodeswhichcanbepersonalizedonthecard andacquireractioncodesstoredintheterminal.EachgroupoftheregistersencodesactionsdefinedbytheissuerandtheacquirerifthecorrespondingTVRbit is1,hencethename.Eachregisterhasthesamelengthof5bytesastheTVR.

Therearethreetypesofregisters:actioncodedenial,actioncodeonlineand actioncodedefault.The“denial”registersspecifyconditionsunderwhicha transactionmustbedeclinedoffline.The“online”registersspecifytheconditionsunderwhichatransactionmustbeauthorizedonline.The“default”registersspecifytheactionwhentheterminalintendedtosendthetransactiononline butfailedtodothatforatechnicalreason.

Theissuer’sregistersarepersonalizedinsuchdataelementsas“IssuerActionCode—Denial”(tag9F0E),“IssuerActionCode—Online”(tag9F0F)and “IssuerActionCode—Default”(tag9F0D)onthecard.Theiracquirer-defined counterpartsarecalledTerminalActionCode—Denial,TerminalActionCode— OnlineandTerminalActionCode—Default,correspondingly.

Todeterminetherequiredcourseofactiontheterminalcanapplyalogical ORforeachpairoftheissuerandterminalregistersandthenapplyalogical ANDtotheresultandtheTVR.Iftheoutcomeisnotzero,therelevantaction mustbetriggered.TheEMVstandardencouragesterminalapplicationdeveloperstooptimizetheprocessbyterminatingadeniedtransactionearlierduring thelifecycleiftheappropriateregisterbitsareset(forinstance,aterminalcan declineanEMVtransactionimmediatelyonceDDAhasfailedifthecorrespond-

ingbitinIssuerActionCodeorDenialregisterissetto1,thusnotextendingthe interactionanylonger).

Toillustratethatconsiderthefollowingexamples.

Scenario1. Bit7oftheTVRbyte2correspondstothe“Expiredapplication” condition.Assumetheissuerhassetits“Denial”counterpart(i.e.,bit7 ofbyte2ofIssuerActionCode—Denialregister)to0,“Online”to1and “Default”to0.Undertheseconditions,iftheapplicationhasexpired,the issuerdoesnotwantthetransactiontobedeclinedofflineandasksthe terminaltogoonlinewithitbutifitfailstodothatallowsattemptingthe transactionofflineauthorization.

NowletusassumethattheacquirerhassettheirDenialbitto0,Onlineto1 andDefaultto1.Inotherwords,theacquirerdoesnotwantthetransaction tobedeclinedonthespotandasksforitsonlineauthorizationbutifitis impossible,prescribesitsofflinedecline.

Withsuchacombinationofactioncodes,theterminaldoesnotdeclinean expiredapplicationimmediately(boththeissuerandtheacquirersettheir Denialbitsto0)andattemptstogoonline(theissuerhassettheOnlinebit to1)andiftheattemptfails,declinesthetransactionoffline(theacquirer hassettheDefaultbitto1).

Scenario2. Bit4oftheTVRbyte2correspondstothe“Newcard”condition. Assumewehaveanissuerwhichsetthe“Denial”bitto0,“Online”bitto 0and“Default”bitto0.letusalsoassumetheacquirerismorecautious andtheir“Online”bitissetto1with“Default”and“Denial”bitsalsoset to0.

Withthiscombinationofactioncodesuponencounteringanewcardthe terminaldoesnotdeclineitoffline(boththeissuerandtheacquirerDeclinebitsare0)andtriestogoonline(theacquirerOnlinebitis1)butif theattemptfails,doesnotdeclinethetransaction(boththeissuerandthe acquirerDefaultbitsare0).

5.3.13GenerationofCryptogramsandIssuerAuthentication

TheterminalcanrequestuptotwocryptogramsfromthecardbyissuingGenerateAC(GAC)commands.BoththefirstandthesecondGACcanresultina transactiondeclineorfullauthorizationincasetheEMVtransactioncancomplete.

However,thefirstGACcanalsoreturnanauthorizationrequestcryptogram (ARQC).Theterminalsendsthecryptogramfortheissuer’sapprovalandupon receivingaresponse,theterminalhastocompletethetransactionbyissuingthe secondGACobtainingafullauthorizationorafulldeclinecryptogramandlater transmittingittothepaymentschemeforclearing.

Thatservestheimportantpurposeofmakingtheissuerandthecardauthenticationmutual:ifthecarddoesnotconfirmtheissuer’sresponsevalidity(possible indicationofaman-in-the-middleattack),thetransactionisrejected.

Asmentionedpreviously(seesection5.3.8.7),thefirstGACcanalsobeused forofflinedataauthentication.Inasomewhatsimilarmanneritispossibleto performtheissuerauthentication(i.e.,issuerresponsevalidationofauthenticity) byeitheraseparateEXTERNALAUTHENTICATEcommandoraspartofthe secondGAC.

5.3.13.1CardActionAnalysis

Uponmakingapreliminarydecisiononthetransactionhandlingmethod,the terminalcommunicatesittothecardbyrequestinganapplicationcryptogram ofaparticulartype.Theyare:TC(TransactionCertificate)indicatinganoffline authorization,ARQC(AuthorizationReQuestCryptogram)correspondingtoan onlineauthorizationattempt,andAAC(ApplicationAuthenticationCryptogram) oranofflinedecline.

ThereisahierarchicalorderofcryptogramswhereTCisthehighestone andAACisthelowestoneinthehierarchy.Theterminalsuggestsaparticular hierarchylevelintherequestandthecardeitherrespondswiththerequested cryptogramordowngradesitbyrespondingwithacryptogramofalowerlevel inthehierarchy.

Theprocessofthecard’sdecisiononthemannerinwhichtheauthorization issupposedtobeperformedisreferredtoas cardactionanalysis.

Therearethreepossiblescenariosforcardactionanalysis.

Scenario1. TheterminalasksthecardtogenerateaTC,thusauthorizingthe transactionoffline.ThecardcaneitherreturnaTCforcinganattempted onlineauthorizationbyreturninganARQCordeclinethetransactionaltogetherbyreturninganAAC.

Scenario2. TheterminalasksthecardtogenerateanARQCforafurtheronline authorization.ThecardcaneitherreturnanARQCortelltheterminalnot tobother,returninganAAC.

Scenario3. TheterminalasksthecardtogenerateanAACandthatiswhatthe carddoes.

IftheterminalreturnsaTCoranAACtothecard,thetransactioniscomplete. TheTCorAACislatersenttotheschemesaspartofthetransactiondetailsin theclearingfile.

Acardcandeclinethetransactionfortwomajorreasons:duetosomelimitationofthetransactionenvironment,suchasrestrictionofaparticulartypeof merchant,orduetoanissuewiththeparticulartransaction.Thestandardcontainsprovisionsforbothscenariosallowingtheterminaltodisplayadifferent

messageineithercase.Thecardmayalsoasktheterminaltosendanadvice messageaboutthedecline(sofar,only“PINtrylimitexceed”hasbeenidentifiedasacasewhenthatmaybenecessary)totheissuer.

5.3.13.2GenerateAC(GAC)Command

Asmentionedpreviously,theterminalcanissuethecommandtothecardupto twotimes.Ifanattemptismadetoissuethecommandforthethirdtime,thecard applicationrespondstoitwith SW1/SW2 setto0x6985.

DuringthefirstissuanceoftheGACcommandtheterminalcanrequestTC, ARQCorAACfromthecardbysettinganappropriatevalueinbits8and7of thecommand’s P1 controlparameter.Valueof0x00correspondstoAAC,value of0x01correspondstoTCandvalueof0x10correspondstoarequestofARQC. Furthermore,theterminal,cansetbit5oftheP1parameterto1torequestaCDA alongsidetheapplicationcryptogramincasetherequestedcryptogramisnotan AAC.

ThesecondissuanceoftheGACcommandoccursifARQCwasgenerated duringthefirstissuance,theterminalwasabletotransmitthetransactionandthe issuerprovidedaresponsetoit.Dependingontheissuer’sdecision,thecardcan performtheissuerauthenticationaspartofthesecondGenerateACcommand.

ItfollowsthatduringthesecondissuanceoftheGenerateApplicationCryptogramcommandanICCcanperformuptothreedistinctoperations:combined dataauthentication,thecryptogramgeneration,andtheissuerauthentication.

GACDataObjectLists

TocalculatetheinputdatafortheGenerateACcommandtheterminalconcatenatesastringofvaluesaccordingtosetofvaluedefinitionsitretrievedpreviously asCDOL1andCDOL2(tags8Cand8D)withCDOL1usedforthefirstGAC commandandCDOL2usedforthesecondGACcommand.

Withfewexceptions,thestandarddoesnotmandateaparticularlistoffields thatarealwaystobeincludedinaCDOL,however,thereisarecommendedminimumsetofvaluesincludingtheamount(s),date,typeandcurrencyofthetransaction(“Amount,Authorized”,tag9F02,“Amount,Other”,tag9F03,“TransactionCurrencyCode”,tag5F2A,“TransactionDate”,tag9A,and“Transaction Type”,tag9C),afewdetailsontheterminal(“TerminalCountryCode”,tag 9F1A,and“TerminalVerificationResults”,tag95,seealsosection5.3.4).

Topreventreplayattacksthelistsofdataobjectsmustincludethe“UnpredictableNumber”(tag9F37)generatedbytheterminal.

TransactionCertificateHashValue

Inadditiontovaluessenttothecardforthepurposeofgeneratingthecryptogram directly,thecardcanalsorequestsomeadditionalvaluefieldstobetakeninto accountindirectlyviaacomputationontheterminalside.

Thatisdonebyrequestinga“TransactionCertificate(TC)HashValue”,tag 98aspartofCDOL1and/orCDOL2.

UponencounteringthetaginaDOL,theterminalchecksthedataobjectlist providedinthe“TransactionCertificateDataObjectList(TDOL)”(tag97).The terminalconcatenatesthevaluesofdataelementsspecifiedinthelistandthen calculatesthehashcodefortheresultingstring.Thenthecardusestheresulting valuetocalculatethecryptogram.

ApplicationCryptogramCalculationAlgorithm

Toputitsimply,anapplicationcryptogramisaMAC(messageauthentication code)ofacertainsequenceofdatafieldscomputedwithauniquekey.Thekey istime-dependent:itisderivedbasedontheATC.

Thestandarddoesnotmandateasetoffieldsforcryptogramgenerationbut itdoesrecommendtoinclude,atminimum,thesamevaluesmentionedaboveas wellasthe“ApplicationInterchangeProfile”(tag82)andthe“ApplicationTransactionCounter”(tag9F36).That,inparticular,meansthattherecommendeddata containsometemporarydetailsonaspecifictransaction,includingitsdate,arandomnumbergeneratedbytheterminalandacounterthatismaintainedbythe card.Thesetofvaluesensuresthatnoreplayattackcanbeperformedwiththe cryptogramasboththeterminal-generatednumberandtheATCareuniqueper transaction.

However,thecryptogramgenerationprocedureisevenmoretime-dependent. DuringthecardissuingpersonalizationstagetheissuerpersonalizesanICCApplicationCryptogramMasterKeyontheICC.Tocalculatethecryptogramthe cardderivesaone-timeApplicationCryptogramSessionKeyfromthemaster keyusingtheATC.

Whileanindividualissuerisallowedtodecideonaproprietarymethodand algorithmforkeyderivation,theEMVstandarddefinesarecommendation.

Accordingtoit,inordertoderivethekeythecardpadsatwo-bytevalue ATCwithzeroestothefulllengthofthealgorithminputblock,whichinthe mostcommoncasebeingtriple-DES,is8bytes.Thenthecardgeneratestwo blocksofvalues,F1andF2,wherethethirdbyte(theonerightafterthebytes allocatedforATC)issetto0xF0and0x0F,accordingly.

TheblocksareencryptedusingtheICCApplicationCryptogramMasterKey, eachoneindividually,andtheencryptedvaluesareconcatenated.Theresulting 16-bytevectorisusedasadouble-length3DESkey.

Then,theICCcomputesthe8-byteMACofthedatausingthejust-derived sessionkey(seesection12.4).

GenerateACCommandandCombinedDataAuthentication

Asmentionedpreviously,whenrequestingaTCoranARQCtheterminalcan setbit5ofthe P1 parameteroftheGACcommandtorequestaCDAalongside

theapplicationcryptogram.UponreceivingtheGACcommandwiththebitset, thecardapplicationbeginstheperformancebycomputingthecryptogramas described.

Thenthecardgeneratesa20-byteTransactionDataHashCode.Afterthatit proceedstosignitwiththeICCPrivateKeymakingtheresultingvalueverifiable bytheterminal(seedescriptionofSignedDataValidationbelow).Theoutcome isstoredinthe“SignedDynamicApplicationData”field(tag9F4B).

Inotherwords,inadditiontothedatalistedinPDOL,thecardadditionally signsallthefieldsreturnedalongsidethecryptogramaswellasthecryptogram itself.ThatmakestheCDAthemostsecuredataauthenticationmethodandpreventsattacksthattamperwithsuchindicatorsasthecryptogramtypeflagsinthe CryptogramInformationData(seenextsection).

GACReturnValue

TheGenerateApplicationCryptogramcommandcanreturnitsresultsintwo formats,convenientlycalledFormat1andFormat2.

InthecaseofaFormat1responsethevalueisaprimitivedataobjector“ResponseMessageTemplateFormat1”(tag80).Theobjectisaconcatenationof CryptogramInformationData(CID),ApplicationTransactionCounter,ApplicationCryptogramitselfandoptionalIssuerApplicationDatavalues.

InthecaseofaFormat2response,thevalueisaconstructeddataobject or“ResponseMessageTemplateFormat2”(tag77).Theobjectcontainsfull BER-TLVobjectswhichmustinclude“CryptogramInformationData(CID)”, tag9F27,“ApplicationTransactionCounter(ATC)”,tag9F36and“Application Cryptogram”,tag9F26.Naturally,CDAcanonlybeusedforFormat2responses whilethe“pure”cryptogramgenerationresultcanbereturnedinbothformats.

TheCryptogramInformationDataisaone-bytevaluecarryingbitsforacryptogramtypeoranindicationofwhetheranadvicemessageonanofflinedecline shouldbesenttotheissuer.Italsohasthreebitsallocatedforanoptionaladvice codeordeclinereason.

ARQCvalidationandcalculationofARPC

InresponsetoanARQCcryptogramsentalongsideotherISO8583datatothe issuer,thelattervalidatesthecryptogramandcalculatestheAuthorizationResponseCryptogram(ARPC).

TovalidatetheARQCtheissuerfirstderivesthemasterkeycorresponding totheparticularcard(basedonPANandPANsequencenumber)andthenuses theATCtoderivethesessionkeyfromit.Afterobtainingthesessionkeywhich inthecaseofusingavalidcardisidenticaltotheonecalculatedbytheICC,the issuerhostusestheunpredictablenumberandotherdataelementsthattransmittedalongsidetheARQCtocalculatetheapplicationcryptogramvalueindepen-

dently.Ifthevaluecalculatedbytheissuermatchestheonetransmittedtoitby theterminal,thecryptogramvalidationisconsideredsuccessful.

TocalculatetheARPC,theissuerhosttakesthe2-byteAuthorizationResponseCode(ARC)value,padsitwithzeroestothefull8-bytelength,XORsit withtheARQCcryptogramandencryptsitwiththesamesessionkeythatwas usedtovalidatetheARQC.

TheARPCandARCvaluesaresentbacktotheterminalandviaittotheICC indataelement55oftheISOmessageas“IssuerAuthenticationData”(tag91) and,optionally,as“AuthorizationResponseCode”(tag9A).Thelengthofthe IssuerAuthenticationDataelementcanbebetween8to16bytesandwhilethe first8bytesalwayscontaintheARPC,theremaining8byteshavethestructure proprietarytotheissuer.However,thefirsttwobytesusuallycontaintheARC.

IssuerAuthenticationCommands

Uponreceivingaresponsefromthepaymentnetwork,theterminalseekstoauthenticatetheissuermakingsurethattheresponsecomesfromagenuineauthoritativesourceandthusalsoensuringthattheparticularstoreisgoingtogetpaid bytheissuerforthetransaction.

TheEMVstandardprovidestwowaystodothat.TheApplicationInterchangeProfilevalueontheICCmayhavebit3or“IssuerAuthenticationis supported”setto1andinthiscaseaseparatecommandorEXTERNALAUTHENTICATEisusedtoauthenticatetheissuer.Ifthebitissettozero,the authenticationiscombinedwiththesecondissuanceoftheGACcommand.

Regardlessofthewaytheauthenticationisperformeditsprocessisthesame:

1.TheICCdecryptstheARPCreceivedfromtheissuerusingthesamesessionkeyformerlyusedtogeneratetheARQC.

2.TheICCXORsthedecryptedresultwiththeARQCandsoobtainsa paddedAuthorizationResponseCode.ItextractstheARCfromthefirst2 bytesofthe8-byteresultvalue.Notethatforasuccessfultransactionthe decryptedARPCistobeidenticaltotheoriginal(encrypted)ARQCsince thetransactionapprovalisindicatedbyzeroes.

3.TheICCcomparesthecalculatedARCwiththeoneprovidedalongside theARPC.Ifthevaluesmatch,theissuerissuccessfullyauthenticated.

ThedatarequiredforissuerauthenticationwiththeEXTERNALAUTHENTICATEcommandisprovidedaspartoftheIssuerAuthenticationDataelement. Attheveryminimum,itincludestheARPCandtheARC.

IftheissuerauthenticationiscombinedwiththesecondGenerateACcommandissuance,theissueraddstag91(“IssuerAuthenticationData”)toCDOL2, thusensuringthatthevalueisincludedintheinputparameterofthecommand.

IftheauthenticationusingtheEXTERNALAUTHENTICATEcommand fails,theterminalsetsthe“Issuerauthenticationfailed”bitoftheTVRto1,

and,correspondingly,takesthevalueintoconsiderationwhendecidingwhich secondcryptogramtorequestfromthecard(TCorAAC).Ifthecombinedauthenticationfails,thecardmakesthedecisiononthereturnedcryptogramtype.

5.3.14ScriptProcessing

Asmentioned,theissuercansendissuerscriptstothecardalongsidearesponse toanonlineauthorizationrequest.

Apossiblescenarioforsuchascriptcouldlockalostorstolencard.For instance,anissuercanreceiveacallaboutalostcard.Ifanattempttoperforma transactiononthatcardismade,oncethetransactionisattemptedonline,ascript istransmittedtoitscardapplicationdisablingthecardpermanently.

Todoso,theissuercantransmittwodataelementsalongsideitsresponseto anARQCcryptogramor“IssuerScriptTemplate1”(tag71)and“IssuerScript Template2”(tag72).Thefirsttemplateistobesenttothecardbeforethesecond issuanceoftheGENERATEACcommand,andthesecondtemplateistobesent tothecardafterthesecondissuanceofthecommand.

Anissuerscripttemplatecontainsoptionalscriptidentifier(“IssuerScript Identifier”,tag9F18)usedbytheterminaltocollectscriptresultsandnotsent tothecard.Aftertheidentifierthescripttemplatecontainsasequenceof“Issuer ScriptCommand”elements(tag86).

Eachissuerscriptcommandfromtheappropriatetemplateistransmittedto thecardas-is.Theterminalchecksthestatuswordsofthecardresponse.Ifa particularscriptcommandwassuccessfulorendedwithawarning,theterminal continuestosendanothercommandtothecard.Iftheresponsecontainsanerror, theterminaldoesnotsendfurthercommandstothecardsetting“ScriptprocessingfailedbeforefinalGENERATEAC”or“Scriptprocessingfailedafterfinal GENERATEAC”bitsintheTVR.

Theterminalcapturestheexecutionresultsbothforeachissuerscriptand eachcommandina5-bytevalue.Eachindividualcommandresultisstoredasa 5-bytesequence.

Thefirstbyteofanindividualcommandresultreflectsthecommandexecutionstatusanditsordinalnumberinthetemplate.Thecommandexecution statusisstoredasthemostsignificantnibble(0means“Scriptnotperformed”, 1-“Scriptprocessingfailed”and2for“Scriptprocessingsuccessful”).Storing ofthecommandsequencenumberinitsparentscripttemplateisoptionaland theterminalcandecidetoalwaysreturnazero(“Notspecified”)orprovidethe commandordinalnumberinthetemplatewithintheleastsignificantnibble.In thelattercase,thefirst14commandsarelabeledwithhexadecimalvaluesof0x1 to0xE,and15andallthefollowingcommandsaredenotedwithan0xF.

Thetrailing4bytescontaineithertheIssuerScriptIdentifier,ifprovided,or4 bytesof0x00ifnoscriptidentifierarrivedaspartofthespecificscripttemplate.

AlthoughtheEMVstandarddoesnotallocateanytagfortheissuerscript results,cardschemesusuallyrequireittobesenttotheissuerunderaproprietary tagelement.

5.3.15TransactionCompletion

ThesecondcalltotheGACcommandandthefollowinggenerationofTCor AACcryptogramsconcludetheEMVtransaction.TheTCissenttotheissueras furtherevidenceforavalidconclusionoftheentiretransactionflow.

6.1Overview

RFIDandlaterNFCtechnologyhaveenabledcontactlessdatatransmissionover anunlicensedglobalradiofrequencybetweendevicesincloseproximity,includingpowersuppliesusingradiowaves.

AboutfiveyearsafterISO/IEC7816wasfirstreleasedin1995,thework concludedinISO/IEC14443,thestandarddefiningphysicalcharacteristics,radiofrequencies,transmissionprotocol,anti-collisionmeasuresandinitialization of proximitycards1

Ataveryhigh-levelviewofacontactlessinteractionseveralchallengescan beidentifiedthattoaconsiderableextenthaveshapedthedifferencesbetween theelaboratecomplexandwell-defined“contact”chipEMVtransactionstandard andtheEMVContactlessfamilyofstandards.

UnlikethetraditionalEMVcasewhereatransactionisalwaysinitiatedby thecardreader,acontactlesstransactioncanbeinitiatedbythecardenteringthe pollingfieldofthereaderdevicetowhichthedeviceonlyreacts.Thatistypical formasstransit,parkinglots,tollroadspaymentscenarios,etc.

Thecarditselfstaysinthefieldoftheproximityreaderforalimitedperiod oftimeandismovedawaybythecardholderregardlessofwhetherthecardand thereaderhavecompletedtheexchangeofcommands.Thattakesmuchlesstime thananonlineauthorizationdoestobecompleted.Inotherwords,bythetimea responsefromtheissuerarrives,thecardisalreadyawayfromthereader.

Finally,thecardisnolongerexactlyacardasitmightbeamobilephone,a keyfob,awristbandoranyotheritemsupportingthesamephysicalprotocol.

Thetransactionoriginationbythecardinsteadoftheterminalcanberesolvedasaminorincrementalchangetoanexistingterminal.Asfortheform factorofthe“card”orpayer’sdeviceapartfromthemagneticstripeorintegral circuitsaslongasaparticulardeviceconformstothephysicallinkrequirements ofISO/IEC-14443,itsformisimmaterial.

Theshortperiodoftimethecardispresentinthepollingfieldofthereader device,however,isamajordifferencethathasconsiderablyimpactedthecontactlessprotocol.

Tobeginwith,thecarddoesnotstayinfrontofthedevicelongenoughto receivearesponsefromitsissuer.Thatautomaticallymeansthatinsomecases unlesstheideaofissuerscriptsistobeforfeitedbyaparticularimplementation, thecardholdermayhavetotapthecardonthereadertwice:thefirsttimetoinitiatethetransactionandthesecondtimetoreceivetheissuerscripts.Furthermore, theEMVtransactionprotocolmayhavetobecondensedintofewercommands toensurethelimitedtaptimeissufficient.

Theconvergenceofthepaymentindustrytoasinglestandardhappenedin severalphases.First,asaresultofsomeearlyexperimentstheISO/IEC14443

1Thesedifferfrom vicinitycards,whichoperateatasomewhatgreaterdistanceandarecoveredby ISO/IEC15693standard

wasdevelopedandacceptedbyallmajorindustryplayers.Laterschemesproceededwiththeirindividualsolutionstothechallengeslistedpreviouslyuntil finallythosewerebroughtunderacommonumbrellastandardofEMVContactlessasalternativeKernels(seesection6.2).

Partlyduetothelimitationsofexistingnetworksandthenecessityofcostly upgradesacrosstheboard,thecontactlessstandardallowstwomodesofoperation:full-gradeEMVandcontactlessmagstripe,thelatterbeingsimilarto part-gradeEMV.

6.2MainConcepts

Initsfirstbook BookA,ArchitectureandGeneralRequirements consistentwith atop-downapproach,theEMVContactlessstandarddescribestheconceptsof thecard,transactionandPOSsystem.

Asmentioned,acardisbasicallyanydevice,item,object,gadgetorunderskinimplant2 compatiblewiththeISO/IEC14443readerphysicallinkrequirements.

AtransactiondefinedbytheEMVContactlessstandarddoesnotdifferin principlefromacontactchipEMVtransactionandhopefullyshouldnotrequire additionalelaborationatthispointinthebook.

Conceptually,a POSsystem consistsofaterminalandareader.Insomescenariostheterminalactivatesthereaderandthenexchangessomedatawithituntil receivingaFinalOutcomefromit.Thereadercommunicateswiththecontactlesscardandapplicationorapplicationsonit,showsmessagestothecardholder, beepsandblinksitsLEDlights.

Asthestandardisunitingmultipleconcurrent(anddiffering)implementationsofapaymentprotocoloverISO/IEC-14443physicallink,eachsuchimplementationiscalleda Kernel.Therefore,thereaderinsidethePOSsystem communicatesnotonlywithoneofmanypossibleapplicationsconformingtoa singleprotocolbutwithmanypossibleKernels,eachofwhichhasaslightlyor significantlydifferentsetofcommands.

Consequently,ratherthanchoosinganapplicationthereaderpicksa combination ofanapplicationandKernelandactivatestheKernel(thusallowingthe supportformultiplesub-protocolsintheformoffunctionallyseparatebutcompliantmodules).Italsoperforms pre-processing (preparatorystepsofatransaction)and,finally,informstheterminalofKernel’sinstructionsonthewayto proceed.ThesetoffunctionsiscalledEntryPointfunctionalityandthestandard

2In2015,amancalledVladZaitsevimplantedsilicon-coatedinternalsofaTroikacard(combined paymentandpublictransitcontactlesscard)intohispalmto“avoidlosinganexpensiveseasonticket”. SincehisskinwastoothickformostreadersinMoscow,theplandidnotwork.Still,Vlad’shanddefinitely meetsthecriteriaofanEMVContactless“card”asoutlinedbyBookAsection4.1atthetimeofwriting.

Table6.1:Kernelsandcardschemescorrespondence

KernelCardscheme

Kernel1JCB,Visa(specialcase,fallbackfromKernel3)

Kernel2MasterCard

Kernel3Visa(preferredchoice)

Kernel4AmericanExpress

Kernel5JCB

Kernel6Discover

Kernel7UnionPay

containsadedicatedbookor“BookB.EntryPointSpecification”describesits processesindetails.

Theversion2.6EntryPointSpecificationdataonKernelsandtheircorrespondingcardschemesarelistedin table6.1.

The Outcomes areKernel’sinstructionstotheEntryPointonthewaytoproceedwiththeprocessing.TheEntryPointcanhandletheoutcomesitselforforwardittotheterminalasthe FinalOutcome.UndercertainconditionstheEntry Pointitselfcangenerateafinaloutcome(usuallywhenitdoesnotfindamatchingcardapplication).

Itisworthnotingthatsinceeach“tap”isshortandtheKernelactivatesan onlinerequestthecardisnolongerpresentinthereader’sfieldwhenaresponse toitarrives.Inthiscase,forexample,ifthereareissuerscriptstobeprocessed, thereprotocolcontainsmeanstorequestaKernelrestartforthesecondtap,as requiredtofinalizetransactionprocessing.

6.3EntryPoint

AnEntryPointcanperformuptofivestepsinatransactionflow.Fourofthem happenbeforethecontrolishandedovertoaparticularKernel,andthefifthis theprocessingofKerneloutcomes.

ThecontactlesstransactionstepsforanEntryPointare Pre-Processing, ProtocolActivation,CombinationSelection,KernelActivationandOutcome Processing

DependingonconditionsanEntryPointcanstartprocessingfromeachof thefirstfoursteps.IntheEMVContactlessStandardtheyarecalledStarts.An EntryPointcanhaveA,B,CandDStartsbeginningpre-processing,protocol activation,combinationselectionormovingdirectlytotheKernelactivation, correspondingly.

6.3.1Pre-Processing

Thepre-processingstepcorrespondstoStartAoftheEntryPoint.Itispresent incaseswhentheterminalinitiatesthetransaction.Theoppositecasewhenthe transactionisinitiatedbyacardenteringthepollingfieldissometimesreferred toas“AutoRun”andasdefinedinthestandardmeansthattheEntryPointis initiatedusingStartB(seesection6.3.2).

Thepre-processingstepisnaturallypresentinvariable-valuetransactionsas thePOSsystemneedstodefinethetransactionamountbeforetheactualtransactioncancommence.

Oncepre-processingiscompleted,theEntryPointactivatesthecontactless readerandproceedstoprotocolactivation.

6.3.2ProtocolActivation

TheprotocolactivationstepcorrespondstoStartBoftheEntryPoint.

Duringthestep,thereaderbegins polling oftheelectromagneticfieldinfront ofit.Thereaderpromptsthecardholdertopresentthecardandthenproceeds withthepolling.Theprotocolitselfsupportstwotypesofphysical-levelprotocols:TypesAandB.InaccordancewiththeISO/IEC14443standard,thereader iscapableofthecollisiondetectionandavoidanceincasemultipledevicesare presentinitselectromagneticfield.

Upontheprotocolactivationstepcompletionthereaderhasdetectedasingle deviceinitsfield,identifieditandestablishedthephysicallinkdialogwithit determiningitstype(TypeAorTypeB).

Insomecases,theEntryPointcanreverttoStartBstatewhenasecondtap ofamobiledeviceisrequired.

Thestepisroughlysimilartochipcard’sresetandanswer-to-reset(ATR) interactionbutcertainlyismorecomplicatedduetothenatureofthephysical link.

Oncethephysicallinkisestablished,theEntryPointproceedstocombination selection.

6.3.3CombinationSelection

ThecombinationselectionstepcorrespondstoStartCoftheEntryPoint.During thesteptheEntryPointhastoselectacombinationofAIDandtheKernelversion.ThesteproughlycorrespondstotheapplicationselectionstepofanEMV contactchiptransaction,however,thereareseveralkeydifferencesdrivenbythe constraintsofthecontactlessenvironmentanditshistory.

Tobeginwith,oneapplicationcanbesupportedbymultipleKernelsavailable attheEntryPoint.AsalsoseenaboveaKernelcanusetheSelectNextOutcome

toinstructtheEntryPointtoskiptothenextsuitablecombination(sameAID andanotherKernel).

Furthermore,duetothecard’stimelimitonpresenceinfrontofthereader directselectionofthesuitableapplication(directapplicationselection)byseries ofSELECTcommandsonterminal-supportedAIDsmayproveunwise.

ToperformcombinationselectiontheEntryPointutilizesavariantofindirectapplicationselection.ItreadsaProximityPaymentSystemEnvironment (PPSE)filefromthecardthatmustbepresentonthecardunderthenameof 2PAY.SYS.DDF01.

APPSEisexpectedtocontainalistofsupportedapplications,associated Kernelidentifiersandpriorityvalues(sothataPPSEcancontainasingleAID withmultipleKernelIDswhichcanbeorderedbypriority).

IfnoKernelIDispresentinthePPSE,theEntryPointreliesontheADF nametopickasuitableKernel.

OncetheEntryPointhaschosenacombination,itproceedstotheKernel activationstep.

6.3.4KernelActivation

TheKernelactivationstepcorrespondstoStartDoftheEntryPoint.UponKernelactivation,theEntryPointhandsovercontrolofcommunicationwiththe contactlesscardtotheactivatedKernel.

TheEntryPointmaygetbacktothestartafteritpickedaKernelandthe latterbyreturningtheSelectNextOutcomeindicatedthatthenextcombination mustbechosen.

OncetheKernelhascompletedorterminateditsinteractionwiththecard application,itreturnstheoutcomefortheEntryPointtohandle.

6.3.5OutcomeProcessing

AtthissteptheEntryPointprocessestheKernelOutcomereturnedbytheKernel. IftheoutcomeismarkedasfinalitisfurtherreturnedtotheterminalbytheEntry Point.Theoutcomesarelistedinsection6.4.

6.4KernelOutcomes

Thestandardlistssevenoutcomessomeofwhichcanalsobereturnedbythe EntryPointitself.Mostoftheoutcomesarereturnedtotheterminalasthefinaloutcome.Outcomeshaveparametersassociatedwiththemwhichcanaffect furtherstepsofthetransactionprocessing.

SomeanalogiesbetweenEMVcontactchiptransactionsandaKernel-card contactlessinteractionoutcomearedrawninthefollowingsections.Itisworth

emphasizingthattheactualcommandexchangeoverthecontactlessinterface betweenaKernelandacardwillpossibly,ifnothighlylikely,differfromthatof theEMVcontactchip.

SelectNext TheoutcomeinformstheEntryPointthatthecombinationofKernelandapplicationisnotsuitablefortheKernel.TheEntryPointisinstructedtotryanothercombination,ifavailable.Ifnoothercombinations areavailable,theEntryPointreturnstheEndApplicationoutcomeasits FinalOutcometothePOSsystem.Otherwise,anothercombinationistried inamannertransparenttothePOS.

TryAgain

TheoutcomeinformstheEntryPointthattheKernelwishesthecard tobepresentedagain.Thatcanbearesultofsuchanerroras“tearing” (cardbeingtakenawaytoofast).

Itcanalsobeusedformobiledevicesrequiringtheconfirmationcodeor otherformofidentification.InsuchscenariostheKernelperformstheinitialexchangewiththecard(mobiledevice),thentherelevantapplication onthedevicerequiresadditionalauthenticationfromtheuser,and,finally, thetransactionisretriedbytheEntryPoint.

ThisoutcomeistransparenttothePOS.

Approved TheoutcomeinformstheEntryPointthatthetransactionhasbeen approved.Uponreceivingit,theEntryPointreturnsittothePOSasthe FinalOutcome.

Theoutcomecanoccurundertwopossiblescenarios:

TheKernelhassuccessfullyauthorizedanofflinecontactlesstransaction.ThatisanalogoustoaTCreturnedbythefirstGENERATEACcommandofanEMVcontactchiptransaction(seesection 5.3.13.2).However,theactualcommandexchangebetweentheKernelandthecardpossiblydiffers.

TheKernelisinvokedfollowinganonlinerequesttothepayment networkforthesecondtimeandhasdecidedtoauthorizethetransaction.ThatisanalogoustoaTCreturnedbythesecondGENERATEACcommandofanEMVcontactchiptransaction.However, theactualcommandexchangebetweentheKernelandthecardis veryprobablydifferent.

Declined

ThisoutcomeinformstheEntryPointthatthetransactionhasbeen declined.Uponreceivingit,theEntryPointreturnsittothePOSasthe FinalOutcome.

Theoutcomecanoccurundertwopossiblescenarios:

TheKernelhasdecidedtodeclinethecontactlesstransactionoffline. ThatisanalogoustoanAACreturnedbythefirstGENERATEAC commandofanEMVcontactchiptransaction(seesection5.3.13.2). Asinthecaseofthepreviousoutcometheactualcommandexchange betweentheKernelandthecardpossiblydiffers.

TheKernelisinvokedfollowinganonlinerequesttothepayment networkforthesecondtimeandhasdecidedtodeclinethetransaction.ThatisanalogoustoanAACreturnedbythesecondGENERATEACcommandofanEMVcontactchiptransaction.Asinthe caseofthepreviousoutcometheactualcommandexchangebetween theKernelandthecardisveryprobablydifferent.

OnlineRequest

TheoutcomeinformstheEntryPointthattheKernelrequested anonlinerequesttodeterminethetransactionstatus.TheEntryPointreturnsittothePOSastheFinalOutcome.

However,usingaparametertheKernelcanindicatethatitwishestobe restarteduponreceivingtheresponse(whichmeansthatthecardholder willbepromptedforasecondtaptoperformissuerauthentication,see section5.3.13,and/ortoprocessissuerscripts,seesection5.3.14).

TheoutcomeisanalogoustoanARQCreturnedbyaGENERATEAC commandofanEMVcontactchiptransaction.

TryAnotherInterface

ThisoutcomecanoriginatefromboththeKerneland theEntryPoint.ItisreturnedastheFinalOutcometothePOS.Itcan occurundertwoscenarios:

TheKernelisunabletocompleteacontactlesstransactionwiththis card,but,fromconfigurationdataavailabletoit,isawareofadditionalinterfaces(chipreader,magstripereader)thatareavailableon thePOS.TheKernelhasthemeanstoindicatepreferenceforthe interfacetobetriednext.

TheEntryPointwasn’tabletoidentifyacompatibleapplicationit couldusetocompletethetransactionandisawareofadditionalinterfaceofthePOS.

EndApplication

ThisoutcomecanalsooriginatefromboththeKernelandthe EntryPoint.ItisreturnedastheFinalOutcometothePOS.Thereare severalpositiveandnegativeflowsthatcouldleadtothisoutcome.

Firstly,theKernelcanencounteranunrecoverableerrorthatwon’tresolve ifthetransactionistriedagainwiththesameapplication(andhencereturningaTryAgainispointless).Alternatively,theEntryPointcanfail toidentifyasuitableapplicationand,therefore,asksthePOStoaskthe cardholdertopresentadifferentcard.

Besidestheerrorconditions,theoutcomecanhappeniftheKerneldecides ithadcompletedprocessingandrequiresnofurtheraction.

TheKernelcanindicatethenextStartthattheEntryPointshoulduseas aparameteroftheoutcomeitsendstotheEntryPoint.Inthatmanner, thisoutcomecanalsobeusedwithmobiledevices,asoneofthewaysto allowthedeviceownertoperformanon-deviceauthentication(confirmationcode,passcode,biometryetc.),analternativetoonedescribedin“Try AgainOutcome”.

6.5ContactlessMagstripe

TheEMVContactlessstandardandits,ineffect,sub-protocolsavailableinthe formofKernels,onlyaffecttheoutermostedgeofthecardpaymentsacceptance network.Therefore,datacapturedatPOSduringacontactlesstransactionmust travelviaexistinginfrastructurethatwasnotnecessarilycapableofsupporting full-gradeEMVtransactionsatthedawnoftheEMVtechnology.

Thatgavebirthtotheso-calledContactlessMagstripePOSentrymode whereastheterminalcommunicateswiththecontactlesscardoramobiledevice inlinewithEMVContactlessstandard,buttheinteractionoutcomeisencoded intoamagneticstripeformatandpackedinto(mostoften)Track2orsometimes Track1discretionarydata.

InthecaseofContactlessMagstripe,averificationvalueoftenreferredtoas dynamicCVCisgeneratedandembeddedintodiscretionarydatapartofTrack 2(seesection2.4.2forformatdetails).ThisisdoneinsteadofproducingafullgradeARQCcryptogramfortransmissiontotheissuer.

ThemethodissupportedbyMasterCard,AmericanExpressandoneofJCB Kernels.

6.6CardholderVerificationMethods

AcardholdercannotbeexpectedtokeepthecardinthereaderfieldwhilepunchinginthePINonthePINpad.Therefore,offlinePINverificationmethodsare notavailableinthecontactlessenvironment.

Withaphysicalcard,acontactlessterminalcaneithergiveupcardholder verificationentirely(NoCVMmethod)andrequestthesignatureorrequirean onlinePIN.

Inthelattercaseafterthecardisoutofthereaderfield,theterminalprompts thecardholderforaPIN,encryptsitandsendstotheissueralongsideothertransactiondetailsaspartoftheonlineauthorizationrequest.

AKernelcanindicatetherequiredCVM-relatedactiontotheEntryPointby passingavaluealongsideitsOutcome.ThevaluesaredescribedintheOutcome ParameterschapterofBookAoftheEMVContactlessstandard.

ThevaluesrequiringafurtheractionareOnlinePINandObtainSignature. TheKernelcanalsodecideonnotrequiringaCVM(NoCVM)ornotproviding anyCVMvaluewhatsoever.

Inthecaseofaconsumerdevice,theKernelcanindicatetotheEntryPoint thatthecardholderhassuccessfullyverifiedtheiridentitybyenteringaconfirmationcodeorperformingsomeformofbiometricauthenticationonthedevice viavalueConfirmationCodeVerified.

6.7UnderstandingKernels

Exceptfortheso-calledcontactlessmagstripe,acontactlesstransactionwhich encounterednoprotocolissue(softwarewasmutuallysupported,nosoftware faultor“tearing”ofthecardfromthereader’sfieldhappened)resultsinacryptogram.ItiseitherapprovedofflineoranARQCcryptogramisgenerated.

Byandlarge,acontactlesstransactionisatrimmed-downversionofafullgradeEMVcontactchiptransactionoptimized,onewayoranother,forthemuch shortertimeframeofasingletap.Infact,eachKernelisaninterestinginsight intothewayengineersdevelopingaparticularcardschemehaveaddressedthe constraint.

Ascommunicationwiththeissuertakesmoretimethanthecardisexpected tobepresentinthereader’sfield,incertaincasesthecardholdermayberequired totaptheircardasecondtimetoprocessissuerscripts.Incaseofaplasticcard asecondtapisrarelyrequiredforatransactioncompletion.

Formobiledevicesfunctioningascardsasecondtapismuchmorecommon.Sincemobiledevicesareusedasmeansforcardholderverification,from theconsumer’spointofviewacontactlesstransactionperformedwithamobile devicerequiresafirsttaporasortofmobilepinorbiometricauthenticationina paymentappfollowedbyasecondtap.

InbothcasestheKernelnotifiestheEntryPointthattheKernelshouldbe restartedandthecardholdershouldbepromptedtopresentthecardagainto completethetransaction.ThatisachievedbysettingavalueofrequestedStart asanOutcomeparametertheKernelreturnstotheEntryPoint.

ManyoftheKernelsthestandardcurrentlysupportsincludeadditionaldata fieldsandadditionalcommandsdefinedforthepurposeofaspecificEMVContactlessimplementation.Suchdatafieldsandcommandsarebelowreferredtoas proprietaryeventhoughformallytheyarepartoftheEMVContactlessstandard.

6.7.1Kernel1—Visa,JCB

Kernel1makestwodecisionsbasedontheamounttobeauthorized.Ifitisbelow theReaderContactlessFloorLimit,thetransactionisauthorizedoffline.Ifthe valueisbelowtheReaderCVMRequiredLimit,nocardholderverificationis performed.

Furthermore,theKernelexpectsaVLPIssuerAuthorisationCodevalueto bepersonalizedonthecard.Ifthevalueisabsent,transactionsarenotauthorized offlineeveniftheyarebelowtheReaderContactlessFloorLimit.

Thetransactionflowbeginswiththeapplicationselection.AftertheSELECT commandtheKernelsendsaGETPROCESSINGOPTIONScommandtothe POSandretrievestheAIPandtheAFL.ThenitreadstheapplicationdatainvokingREADRECORDcommands.

Oncetheapplicationdatahasbeenread,theKernelmakesadecisionregardingofflineoronlinetransactionauthorization.

Inthecaseofanofflineauthorization,theKernelreliesontheso-calledfDDA (fastDDA)forcardauthentication.Fromthecard’spointofviewthatisastandardDDA,buttheKernelcompletesauthenticationafterthecardhasleftthe pollingfield.Toauthenticatethecard,theKernelinvokestheINTERNALAUTHENTICATEcommandnormallyonlysendingtheUnpredictableNumberas itsparameter.TheterminalsubsequentlyusestheVLPIssuerAuthorisationcode, Track2and,ifavailable,Track1discretionarydataintheclearingrecord.There isnofurtherinteractionwiththecardaftertheINTERNALAUTHENTICATE command.

Ifthedecisionistogoonline,theKernelinvokesaGENERATEACcommand.ItonlyexpectstoreceiveanARQCbackfromthecardterminatingthe transactioninanyothercase.

TheKernelcheckstheapplicationexpirydateaftereitherINTERNALAUTHENTICATEorGENERATEAPPLICATIONCRYPTOGRAMcommands.In thelattercasenosecondGACinvocationisperformedandnoissuerscriptsare processed.

6.7.2Kernel2—MasterCard

TheKernelsupportstwoprocessingmodes:MagstripeandEMV.Furthermore, itsupportssomemethodstorecoverfromcardtearing(prematureremovalofthe cardfromthereaderfield)andsupports datastorage ortheabilitytousethecard asadatascratchpad.

Thedatastorageabilitycomesintwoflavors:standalonedatastorageorSDS requiringaseparatesetofcommandstoreadandupdatethedataandintegrated datastorageorIDSprovidingdataaccesspiggybackingonEMVcommandsof otherdesignation.DatastorageofaseparateKernelisnotinteroperablewith another.

InadditiontostandardEMVcommandstheKernelusesseveralproprietary commands.

Thetransactionflowbeginswiththeapplicationselection.AftertheSELECT commandtheKernelsendsaGETPROCESSINGOPTIONScommandtothe POSandretrievestheAIPandtheAFL.

AccordingtotheEMVstandardbit8ofthesecondbyteofAIPisreservedfor EMVContactlessimplementation.AsforKernel2,itisusedtoindicatewhether thecardsupportsEMVContactlessornot.

InthemagstripemodetheKernelreadscarddatausingtheREADRECORD command.ThentheKernelgeneratesanunpredictablenumberandafterwards usesaproprietaryCOMPUTECRYPTOGRAPHICCHECKSUMcommandto retrievetheso-calledCVC3ordCVVvaluefromthecard.Afterthatitplacesthe unpredictablenumberandthecalculatedvalueintodiscretionarydataofTrack2 valueitgenerates,and,ifpersonalizedonthecard,Track1aswell.Thenthevaluesaresenttotheissuerforauthorizationonline,conformingtomagneticstripe transactionformatbutbearingcryptographicchecksumgeneratedbyanICCover contactlessinterface.

ThesupportofcontactlessEMVmodemeansthatthecardcansupportone ofthetwoformatsofdatastorage.TheKernelandthecardalsohavetoolsto handleatorntransaction.

IfthecardsupportsSDS,theKernelissuesaGETDATAcommandtoretrievestoragecontents.ItthenreadsapplicationdatausingtheREADRECORD command.Ifthedatastorageisintegrated,theKernelretrievesstoreddataas partoftheREADRECORDcommand.

WithSDS,theKernelinvokesthePUTDATAcommandtostoredataonthe card.

AfterreadingthedatafromthecardtheKernelmayidentifyatransactionasa “torn”oneortheonethatwasalreadyattemptedbutdidnotcomplete.IftheKernelconsidersthetransactionatornone,itissuestheRECOVERACcommand tothecardaskingnottogenerateanewcryptogrambuttoretrieveapreviously generatedoneinstead.Thecardmayeitherrespondwithapreviouscryptogram orreturnanindicationthatthereisnoapplicationcryptogramtorecoverandthe Kernelmayproceedwiththetransactionasanewone.

IfthetransactionwasnotidentifiedastornortheRECOVERACcallreturned nocryptogram,theKernelinvokestheGENERATEACcommandretrievinga cryptogramfromthecard.Kernel2reliesonthestandardEMVmechanismof requestingacryptogramtypeandhavingthecardcomplyordowngradeit(e.g., theKernelcanaskforaTCandobtainanARQCinresponse).Ifthedatastorage isintegrated,theKernelsendsthevaluestostoreaspartofGACparameters.

AccordingtotheoutputoftheGACcommandtheKerneleitherauthorizes thetransactionofflineordeclineitorgoonlinefortheauthorization.TheKernel canalsoattemptaCDAaspartoftheGACcall.

IftheKernelfailedtoreceivethecryptogram,itstoresthePANandthecard sequencenumberinaninternallogandinthecaseofasecondtapattemptstorn transactionrecovery.

Nofurtherinteractionwiththecardfollowsthecryptogramgenerationas Kernel2doesnotsupportthesecondGACortheissuerscripts.

6.7.3Kernel3—Visa

UnlikeKernel1,Kernel3providessupportforasecondtapofthecardallowing theissuerscriptstobetransmittedtothecard,ifnecessary.TheKernelsupports integrateddatastoragefunctioningonthesimilarprinciplestypicalofKernel2 butisnotcompatiblewithit.

AkeyfeatureofKernel3isusingofitssingleGETPROCESSINGOPTIONScommandtoperformfunctionsthataredividedbetweenGPO,INTERNALAUTHENTICATEandthefirstGACinaregularEMVflow.

WhenduringEntryPoint’sCombinationSelectionsteptheapplicationisselected,thereturnedFCImaycontainatagpointingtotheIntegratedDataStorageDirectory.Ifthetagispresent,theKerneloperatesinIDSmodereadingand updatingtheIDS,asrequired.Ifthetagisabsent,theKernelonlyperformsa paymenttransaction.

AftertheApplicationSelection,theKernelinvokestheGETPROCESSING OPTIONScommandbasedonthePDOLobtainedaspartoftheFCI.ThePDOL alwayscontainsamandatoryproprietaryelement,‘TerminalTransactionQualifiers’(tag9F66)orTTQ,containingtheindicationsofterminalcapabilitiesas wellasabitindicatingwhetheronlineorofflineauthorizationisrequired.

InresponsetotheGPOcommandthecardapplicationreturnstheprocessing options,fDDAvalueandanapplicationcryptogrampossiblydowngradingan offlineauthorizationtoanonlineone.Thecardalsoreturnsaproprietaryelement called“CardTransactionQualifiers”(tag9F6C)orCTQ.

ThentheKernelproceedsissuingREADRECORDcommandstoretrieve applicationdatafromthecard.Oncethedataisretrieved,theKernelisableto performofflineauthentication.Iftheauthenticationissuccessful,thetransaction isconsideredauthorizedofflineorissenttotheissuerforanonlineauthorization attempt.

Ifboththeissuerandthecardsupportissuerupdateprocessing,andanonlineauthorizationisrequired,theKernelinstructstheEntryPointviaadisplay messagetorequestthecardtobepresentedagainandasksforareturntoStartB. TheEntryPointhandlestheonlinerequestandrestartstheKernel.Uponrestart, theKerneldetectsthataresponsefromtheissuerhasarrivedandperformsthe completionofthepreviouslystartedtransactioninsteadofstartinganewone.

TheKernelissuesanEXTERNALAUTHENTICATEcommandtothecard tochecktheIssuerAuthenticationData.Ifsuccessfulandiftheissuerscriptsare provided,theyaresenttothecard.

Incasetheintegrateddatastorage(IDS)supportisindicatedintheFCI andtheterminalsupportsit,theflowofthefirsttap(newtransaction)slightly changes.IntheIDSmodeaproprietaryEXTENDEDGPO(EGPO)command issentbythereaderinsteadofastandardGETPROCESSINGOPTIONScommand.ItcontainsadditionaldataelementsallowingtheIDSupdate.Conversely, aftertheEGPOreceivestheresponsethedatareadbytheREADRECORDalso containdatafromtheIDS.

6.7.4Kernel4—AmericanExpress

Kernel4supportsboththeEMVandmagstripecontactlessmodes.Thecard indicatesthedesiredmodeviaAIPwherebit8ofbyte2issetto1inthecaseof EMVtransactionandto0forthemagstripe.

TheKerneldefines Offline,DelayedandPartialOnline modesoftransaction authorization.Theofflinemodeisthestandardofflineauthorization,thepartial onlinecorrespondstoonlineauthorizationwithotherKernelsandiscalledpartialbecausenosecondGACcallismade.Thedelayedauthorizationisaspecial handlingofcasesinwhichthetransactionissenttotheissuerforreservation offundsatalaterstage.Inthecaseofdelayedauthorizationtheterminalconsidersthetransactionapprovedbutsendstheonlinemessagetotheissueronce connectionisavailable.Thedelayedauthorizationistransparenttothecard.

TheKernelalsosupportsaMobileCVMinformofacodewhichcanbe enteredintothemobiledeviceforcardholderverification.IfaMobileCVMis required,theKernelreturnsaTryAgainOutcometotheEntryPointallowing thecardholdertoperformverificationandtaptheirdeviceatthereaderonce again.IfaMobileCVMisperformed,thecardreturnesitsresultstoeitherGET PROCESSINGOPTIONSorGENERATEACcommands.

AmongotherKernelspecialfeaturesistheCDOL-Switchwhichisthename forthecard’sabilitytoreturndifferentCDOLsinEMVandmagstripemodes.

Otherwise,theKernelcommandflowfollowsstandardEMVtransactionuntil thefirstGAC.OnlySDAorCDAofflineauthenticationmethodsareallowed,i.e., noINTERNALAUTHENTICATEcommandcanbesenttothecard(seesection 5.3.8).

TheKernelusesREADRECORDcallstoreadapplicationdataintheEMV modeandissuesaGETDATAcommandinmagstripemodetoretrievetheATC.

EMVGACissimilartothecontactEMVcommand.Inmagstripemodea limitedsetofdataelementsissentasinputtotheGACcommandandthecryptogramishandleddifferently.Tobeginwith,aTCcryptogram,ifreturnedbythe card,causestheterminaltodeclinethetransaction.Also,sincetransmissionof thefullcryptogramvaluetotheissuerisimpossible(hencethemagstripemode inthefirstplace),thecryptogramisencodedintodiscretionarydatasectionof Track2(seesection2.4)bydiscardingitsfirst5bytesconvertingthevalueto

decimaldigitsandplacingthelastfiveofthemintheDDsectionoftheTrack2 datafield.

6.7.5Kernel5—JCB

Kernel5supportsbothEMVandmagstripemodes.AsimplifiedversionofEMV modeortheLegacymodeisalsodefinedinthedocumentation(itskeydifferencesarenoofflinecardauthentication,nosupportforofflineauthorizationand noissuerscriptprocessing/secondtap).Thecardindicatesthedesiredmodevia AIPwherebit8ofbyte2issetto1inthecaseofEMVtransactionandto0for themagstripe.TheLegacymodeisindicatedinthePDOLbyanadditionaldata element.

TheKernelalsoallowsfortwoissuerupdatesmodes:eitherviaasecondtap orbycontinuouslyholdingthecardinthereaderfield.TheKernelmustsupport bothoptionsastheirchoiceisindicatedbythecard.Kernel5alsosupportstorn transactionrecovery.

Kernel5transactionflowinEMVmodeissimilartotheContactEMVtransactionflow.Kernel5onlysupportsCDAmodeofofflinecardauthentication (seesection5.3.8)and,therefore,theINTERNALAUTHENTICATEcommand isnotpartofKernel5transactionflow.

ThefirstGENERATEACcommandmayreturnavalueindicatingmobile CVM.Inthiscase,theKernelreturnsanEndApplicationOutcometotheEntry PointinstructingittoreturntoStartBanddisplayanappropriatemessagetothe cardholder.

IncasetheKernelsupportsissuerupdates,inresponsetoGACthecardmay returnan“IssuerUpdateParameter”(tag9F60)indicatingoneofthetwosupportedmodesforissuerupdatesornotifyingthatnoissuerupdateisrequired.If updatesarerequired,thecardmayrequestthecardtobeheldinthereaderfield untilthetheissuer’sresponsearrives.Inthatcase,theKernelreturnsanOnline Requestoutcomewiththe“PresentandHold”parameter.Otherwise,thecard mayaskforthesecondtap.

RegardlessofthechosenmodeuponreceiptofdatafromtheissuertheKernel transmitsscriptsfromthe“IssuerScriptTemplate1”(tag71)tothecard.Ifthe IssuerAuthenticationDataorIssuerScriptTemplate2arepresentintheissuer response,theKernelinvokesthesecondGACcommandandhandlesitsoutcome aswithastandardEMVtransaction.

Inmagstripemode,aMDOL(“MagstripeDataObjectList”,tag9F5C)proprietaryvaluecanbepersonalizedonthecard.ItisreadbytheKernelattheRead ApplicationDatastage,butifabsent,adefaultsetofvaluesisdefinedinthestandard.ThentheKernelissuesaGETMAGSTRIPEDATAproprietarycommand tothecardretrievingafullTrack2imageinresponse.AfterthattheKernel referstothelastdatanibblecontainingacodeforthepreferredCVMmethodto beperformed.Magstripemodetransactionsarealwaysauthorizedonline.

IfthecardtearsawayduringtheGACcommand,theKernelallowsitsrecoverywithoutgeneratinganewcryptogram.IfKernel5considersthetransaction astorn,itentersthetorntransactionrecoverymode.Inthemodeaproprietary ECHOcommandissenttothecardafterthefinalSELECTcommand.Ifthe responsetotheECHOcommandis9000,theKernelproceedswiththeregular EMVflowbutinresponsetotheGACthecardreturnsitspreviouscryptogram insteadofgeneratinganewone.

6.7.6Kernel6—Discover

Kernel6supportsbothEMVandmagstripemodes.Thereisalsoasecond magstripemodecalledLegacyMagstripemode.Thesupportforitisdetermined byAID:thereisanAIDforEMVandMagstripemodesandanotheroneforthe LegacyMagstripeMode.

TheKernelreliesontheGETPROCESSINGOPTIONScommandtoretrieve offlinecardauthenticationdataaswellasanapplicationcryptogram.InEMV mode,theissuerscriptsaresupportedviaasecondtap.IncaseofmobileCVM, theKernelreturnstheTryAgainOutcometotheEntryPoint.

Aftertheapplicationhasbeenselected,theKernelissuesasingleGPOcommand.InEMVmode,theGPOcommandcontainstheapplicationcryptogram andsomedataforofflinecardauthentication.TheKernelmakesitsdecisionon thenextsteps(onlineorofflineauthorization)basedonthetypeofcryptogram returnedintheGPOresponse.

AfterreceivingtheGPOresponseandincaseitcontainedanAFL,theKernel issuesREADRECORDcommandstoreaddatafromthecard.

InEMVmode,thedatareadisusedtoperformofflinecardauthentication.

Inmagstripeorlegacymagstripemodes,theKernelretrievesTrack1and Track2datafromthecardinresponsestoREADRECORDcommands.

AcardcanalsosupporttheDynamicCVV(DCVV)functionality.Inthat casethePDOLcontainsanUnpredictableNumber,andduringREADRECORD aDynamicCardVerificationValue(DCVV)(tag9F7E)ispresentinthedata read.

UponencounteringtheDCVVdata,theKernelplaces2least-significantUnpredictableNumberdigitsitformerlygeneratedandtheDCVVvalueitretrieved fromthecardinTrack1andTrack2valuesatfixedoffsetsasdefinedinthe standard.

IncaseIssuerScriptupdatesarerequired,afterrestartingtheKerneltransmits themtothecardonebyonewithoutperformingthesecondGACcall.

6.7.7Kernel7—UnionPay

Kernel7supportsEMVmodeonly.Noissuerscriptprocessingissupportedbyit.

ItreliesonasingleGETPROCESSINGOPTIONScommandtoretrievean applicationcryptogram.Furthermore,itonlyusesCDA(infDDAform)inthe caseofanofflinetransactionauthorization.

OncetheGPOcommandisissuedandtheresponsetoitarrivesandifthe applicationcryptogramtypereturnedisARQC,thecardcanleavethereader fieldaftertransmissionoftheGPOcommandresponse.

InthecaseofaTCreturnedbytheGPOcommand,thecardalsocomputes theofflineauthentication(fDDA)value.TheKernelproceedstoissueREAD RECORDcommandsuntilthedatarequiredtoauthenticatethecardarefully retrieved.

FormobiledevicestheGPOcommandreturnsastatuswordof6986.Inthat case,theKernelreturnsaTryAgainOutcometotheEntryPointrequestingto restartStartB.

OTHER PROCESSESAND STANDARDS

IV

However,thesetechnicalmeanscannotcoverallpossiblebehaviors(ormisbehaviors)oftheschememembers,cardholdersormerchantsincludingbothintentionaldeviationsfromtherulesandhonestmistakes.

Toallowschemeparticipantstoraiseandmanageissuesrelatedtosuchdeviationsfromprocessingrulesschemessupporttwomajorprocesses: disputemanagementandarbitration toresolvedisputesbetweenparticipantsand scheme compliance tohandlenon-complianceofpartieswithschemerules.

7.1DisputeManagementandArbitration

7.1.1OverviewofGenericDisputeLifecycle

Disputemanagementandarbitrationprocessesslightlyvarybetweenschemes butbyandlargecanbedescribedasasubsetoftheprocessdescribedin table7.1 andinitiatedbytheissuer.

Thearbitratedflowcanpotentiallycontainastepoffilingapre-arbitration casewiththeschemewhentheotherpartycanconcedethedisputeandavoid theriskofschemedecisionnotinitsfavor,whichisaccompaniedbyarelatively highfee.Itisusuallypossibletoskipthestepandgodirectlyforarbitration approachingtheschemedisputeresolutionteamfordecision.

Table7.1:Non-arbitrateddisputelifecycle

IssuersendsAcquirerresponds

Retrievalrequest

Requestforretrievalofsupporting documentationforatransaction.

Fulfillment,explicitnon-fulfillmentor noresponse

Supportingdocumentationis providedinthecaseoffulfillment.

Representment,acknowledgementor noresponse

Chargeback

Actualdisputeoftheoriginal transaction.

Supportingdocumentationinthecase ofrepresentment.Ifnoresponse,the chargebackisconsideredacceptedby theacquirer.Certainschemes encourageproactive acknowledgementofaccepted chargebacksbytheacquirer.

Secondchargeback

Furtherchallengetothetransaction withadditionaldocumentstosupport theclaim.

Noresponse,pre-arbitrationor arbitration Inthecaseofnoresponse,the chargebackisconsideredacceptedby theacquirer.

7.1.2RetrievalRequestsandFulfillments

Asanoptionaltoolforissuerstoinvestigatepotentialdisputes,schemesprovide amechanismoftencalled“retrievalrequest”.Asitsparttheissuersendsarequesttotheacquireraskingtoprovidesupportingdocumentationforaparticular transaction.Theacquirercantypicallychoosenottorespondtoarequestorto respondbyeitherprovidingthedocument(s)orrefusingtodoso.

Theacquirer’sresponsetoaretrievalrequestwithdocumentationiscalled fulfillment andaresponsewithoutdocumentationiscalled non-fulfillment.Itis notmandatoryforanacquirertorespondtoaretrievalrequest.

Typically,thedocumentationincludessalesdraft.Fore-commerceorEMV transactionsinwhichthecardholdersignsnoslip,allthedatanecessaryfora draftisfoundintheacquirersystemsorhasalreadybeentransmittedtothepaymentnetwork.However,incaseswhenlegacyschemesystemsmandateprovisioningofasalesdraftacquirersgenerateso-called“substitutedrafts”orsubdraftscontainingallnecessarytransactiondetailsinanimagefile.

Itisusuallyintheacquirer’sbestinteresttoprovidesupportingevidenceto theissuerasthatcanhelpavoidasubsequentchargeback.

7.1.3ChargebacksandRepresentments

A chargeback isademandtomakegoodthecardholder’slossonafraudulentor disputedtransaction.Suchademandmayormaynotfollowaretrievalrequest.

Achargebackisinitiatedbytheissueronbehalfofthecardholderandinfull disputecycleisdeliveredtotheacquirerinformofafinancialrecordthatcan arriveinanincomingsettlementfileorinformofacasethatappearsinanonline disputemanagementsystemprovidedbythescheme.

Eachchargebackcontainsanindicationofthereason(fraud,technicalproblemwiththetransactionordisputeofthetransactionbetweenthemerchantand thecardholder)andtheissuingbankcan,incasetherulesfortheparticular chargebackreasonrequirethat,provideevidenceinformofsupportingdocumentationavailableviaonlinedisputemanagementsystem.

Achargebackcanbeofthefullamountoftheoriginaltransactionoronly foritspart(if,forinstance,onlysomegoodsorserviceshavenotbeendelivered andarebeingdisputed).Multiplepartialchargebacksarepossibleforasingle transactionprovidedthatthetotalofallpartialchargebacksdoesnotexceedthe amountoftheoriginalpurchase.

Previously,schemesusedtodefinealargevarietyofvariousreasoncodes thussimplifyingtheclassificationofchargebackcasesontheacquirerside.For example,asituationwhenthegoodshavenotbeendeliveredbythemerchantand asituationwhenserviceshavenotbeenprovidedbythemerchantareencoded withseparatereasoncodesallowingtheacquirerrepresentmentrightsincase thereasoncodewasnotchosenproperly.Thatwassubsequentlyamendedand

thereasoncodesforchargebackswerereducedfromseveraldozenstoahandful simplifyingthejobofanissuerandplacingmoreburdenontheacquirer’sdispute managementteam.

Onceachargebackisdeliveredtotheacquirer,itsamountiscollectedfrom theacquirerbydeducingitfromthecorrespondingsettlementamount(forexample,internationalsettlementontheprocessingdatewhentheschemesentthe chargebacktotheacquirer).

Iftheacquireragreeswiththechargebackamountordecidesthatthecostof theirfurtherstepsishigherthanthebenefitfromwinningthedisputedamount back,theacquirercaneithersendanacknowledgementofthechargebackorsimplydonothing.Ifaschemesupportschargebackacknowledgements,members areusuallyencouragedtousethem.

Theacquirercanchoosetoeitherabsorbthecostsortorollthemonthe merchant.

Someofthepossiblereasonsforachargebackinclude:

Technicalfaults,errorsatthepointofsale,wrongcurrencyconversion ratesandlatepresentmentsoftheoriginaltransaction.

Fraud,transactionnotauthorizedbycardholder,recurringbillingfora servicethatwascanceledbythecardholder.

Goodsorservicesnotdeliveredorprovided,fullyorinpart.

Special/industryspecificdisputes.Forinstance,someschemesapplycertainrulestochargesacarrentalbusinesscanmaketoacustomercard. Anotherexampleisanautomaticchargebackrightforcounterfeitgoods.

Shouldtheacquirerdisagreewiththechargeback,theycanperforma representment (sometimescalled secondpresentment).Duringarepresentmentthe acquirersubmitsnecessarydetailsordocumentstotheissuesviatheschemeas wellassendsthemafinancialrecord.Then,theacquireriscreditedtherepresentmentamountbythescheme.

Sometimesitissufficienttosimplysendafinancialrecordwhenitsfieldsallowpassingenoughdatafortheissuertoprocesstherepresentment.Forinstance, iftheacquirerhasreceivedaduplicatechargeback,noadditionaldocumentsare needed.Ifthetransactionhasalreadybeenrefunded,theacquirercanprovidethe referencenumberoftherefundaspartoftherepresentmentfinancialrecord.

Inothercasesthesubmissionofadditionaldocumentsmayberequired.They mayincludesalesdraftswithcardholdersignaturesorotherevidencethatthe goodswereindeedshippedortheservicesrendered.Forcard-not-presenttransactions,especiallye-CommerceandPIN-basedauthorizations,whennosignaturehasbeenprovided,theschemesanywayoftenrequirethatasalesdraft shouldbesubmittedtotheissuerduringtherepresentment.Suchasalesdraftis

commonlygeneratedbasedonthedatafromtheacquirerdatabaseandiscalled asubstitutedraftorsub-draft.

Asforchargebacks,arepresentmentcanbepartialorfull.Arepresentmentis consideredpartialifitdoesnotcoverthefullamountoftheoriginaltransaction andisconsideredfullifitdoes.

Toillustrateit,considerthesetofscenariosofpossibledisputesona100 EURtransactionbytheissuerwitharesponsebytheacquirerin table7.2.

7.1.4SecondChargeback

Incasetheissuerdisagreeswithmaterialsprovidedwiththerepresentment,certainpaymentschemesallowsendingthemanadditionalchargebackcalled secondchargeback or arbitrationchargeback.Uponthesecondchargebacktheissueriscreditedwiththedisputedamountandtheacquirerisdebitedwithit.

Schemesmayrelyonsecondchargebackasanadditionalstepinthenonarbitrateddisputeresolutionprocess,however,thenumberofcardschemessupportingthisstepdecreasesovertheyears.

7.1.5Allocationvs.Collaboration

Inrecentyearsschemesbegantodeployakindofshort-circuitedprocessfor technicalandfraud-relatedchargebacks.

Accordingtothenewrulesthereisnoadversaryprocessincertaincases:the schemeallocatesasidethatbearstheliabilityforthechargeback.Thereisno optiontoproceedinanon-arbitratedmannerbeyondthatpointandachallenge toachargebackrequiresamuchcostlierpre-arbitrationorarbitration.

Todistinguishtheshortflowfromthestandardone,schemesusesuchaterm as allocation (forschemedecisiononchargebackliability)asopposedto collaboration (forafullnon-arbitratedexchange).

processiscalled arbitration andistriggeredbythelastpartyinthedisputeflow turningforresolutiontothescheme.Incertainsolutionsthearbitrationstepis precededbythe pre-arbitration stepwhentheappropriatepartynotifiesitscounterpartthatitisabouttoapproachtheschemeforarbitrationprovidingthelast opportunitytoagreetothedispute.

Asarbitrationisamanualprocessthatinvolvesdisputeresolutionspecialists employedbyschemes,membersarediscouragedfromunnecessarilyrelyingon themandtheireffortiscompensatedbyschememembers.

7.1.7LiabilityShift

Incertaincasesschemesimplementsomerulesdenyingacertainpartyitsusual disputerights.Thesearecalled liabilityshifts andareusedasatooltomotivate institutionstowardsacertainbehaviormostlytoimplementthelatesttechnologicalfeaturesforfraudpreventionandauthenticationandcardholderprotection.

Forexample(specificrulescanchangeorvarybetweenschemes):

Ifatransactionhasbeenauthenticatedusing3DSecure(undercorrespondingbrandname)orEMV3D-Secure,theissuercannotdisputeit claimingthatthecardholderdoesnotrecognizeit.Incaseadisputeof thesortarrivestotheacquirer,theacquirercanrepresentthedisputeon thegroundsofliabilityshift.

Likewise,theimplementationofEMVtechnologywasaccompaniedbya liabilityshiftinfavoroftheimplementingparty.Atransactionprocessed onamagstripe-onlyterminalwithacardhavinganembeddedchipcanbe disputedbytheissuerforthereasonofnotbeingauthorizedbythecardholderandtheacquirerisnotabletorepresentitexceptforatechnicality inthechargebackmessageitself.

7.1.8StreamlinedLifecycle

Originally,thedisputelifecycleswereidenticalfortechnicalissues(suchas mismatchofattributesbetweenauthorizationandclearingtransactions),fraudrelatedissuesandgenuinedisputesbetweenmerchantsandcardholders.

However,withevolutionofnetworkauthorizationandclearingsystemstowardstheincreaseofdataintegrityenforcementsandvalidations,schemesbeganintroducingaleanerprocessfortechnicalissuesthatcanbeanalyzedand resolvedbasedontransactionattributesonly.

Thestreamlinedprocessimpliestheallocationofliabilityupondisputesubmissionbythescheme.Inotherwords,insteadofanexchangeofdisputemessagesanddocumentationbetweentheissuerandtheacquireruponachargeback

submissionbytheissuerthescheme,decidesonthewinningpartyandperforms thecorrespondingfinancialmovementsaccordingly.

Followingsuchanallocationofliabilityboththeissuerandtheacquirercan appealaskingtomovethedisputecasetoarbitration.

7.2Compliance

Atanytimeofthedisputemanagementcycleoratanytimeatallregardless ofaparticulardispute,amembercanraiseacomplaintregardingschemerules complianceagainstanothermemberortheschemeitself.

Typicalcomplianceprocedurepermitsbutdoesnotrequirethecomplaining membertofirstnotifythecomplaineewitha pre-compliance notificationdescribingthenon-compliantbehaviorandallowingthecomplaineetoresolvethematterbeforetheschemecomplianceteamstepsin.Thecomplaineemayrespondto thecomplainer,however,shouldtheanswerbeunsatisfactory,thecomplainercan proceedwithacompliancecasethatistobehandledbytheschemepersonnel.

Toillustrateitconsiderthefollowingscenarios.

Scenario1. Anacquirerwasrepeatedlysendingcard-not-presentandcard-onfiletransactionseventhoughtheresultcodefromtheissuerinstructedthe acquirerthattheauthorizationforthecardhadbeenrevoked.Eachdecline triggersafeetheissuerpaystotheschemeandtheacquirerdidnotobey theresponsecodeandcontinuedattemptedauthorizations.Thescheme authorizationservicedidnotblockthosetransactionssotheissuerfileda compliancecaseagainsttheacquirer.

Scenario2. Anacquirerreceivedseveralchargebacksfromanissuerontransactionswhichhavingbeenfullyauthenticatedwith3DSecureshouldhave enjoyedtheliabilityshift(seesection7.1.7)forthatparticularchargeback reason.Acheckwithtransactioninvestigationtoolsandthesupportofthe schemeindicatedthatthetransactionshadbeensentcorrectlybutreached theissuerwiththefullauthenticationindicatorstrippedfromthem.To promptactiononbehalfoftheschemetheacquirerfiledacompliance caseonthescheme.

Consideringhowfewdetailsarerequiredtoperformacardpayment,itisobvious thatcardandcardholderdatasecurityisparamounttocombatfraud.Following asignificantnumberofdatasystembreaches,bothlargeandsmall,thecard industryrespondedbyself-organizingintothePaymentCardIndustrySecurity StandardsCouncilorPCISSC.Thecouncilwasformedin2006byAmerican Express,Discover,JCB,MasterCardandVisa,anditsgoalwastocreateand maintaindatasecuritystandardsrelevanttopaymentcards.

TheprincipalstandardthecouncildevelopsandmaintainsisthePCIDSS orPaymentCardIndustryDataSecurityStandardprovidingtechnicalandoperationalrequirementsforaproperprotectionofsensitiveandaccount-related data.Thestandardprovidesend-to-endrequirementsbeginningfromsoftware, itsconfiguration,operatingsystemsanddatabasesitrunson,policiesandproceduresarounditandallthewaythroughtorequirementsforphysicalaccessto hardwareandfacilities.Thecouncildefinesmethodsforself-assessmentaswell asforindependentauditandmaintainsaregistryofapprovedassessors.

ThePCISSCalsoissuesandmaintainsadditionalstandardswithnotable inclusionsofPCIPADSS(PaymentApplicationDataSecurityStandard)and PCIPTS(PINTransactionSecurity)aswellassomemorefocusedstandards forpoint-to-pointencryptionandHSMssecurehandlingandmanagement(see section8.3.1).

8.1PCIDataSecurityStandard(PCIDSS)

ThePCIDataSecurityStandardcoverstechnicalandoperationalrequirements designedtoprotectaccountdata.Itdefinesthecardholderdataenvironmentor CDEaspeople,processesandtechnologiesthatstore,processortransmitcardholderorsensitiveauthenticationdata.Consequently,itsrequirementscoverall thecomponentseitherincludedinorconnectedtothecardholderdataenvironment.Forinstance,ifamachinedoesnotstore,handleortransmitaccountdata butresidesonthesamenetworksegmentasanothermachinedoes,PCIDSS requirementsextendtothemachineanyway.

8.1.1AccountData

ThePCIDataSecurityStandardexplicitlydefineswhichdatavaluesareconsideredaccountdata.Accountdataconsistsofcardholderdataandsensitiveauthenticationdata.

CardholderdataorCHDisthePrimaryAccountNumber(PAN),cardholder name,servicecode(seesection2.4.4)andcardexpirationdate.Thelatterthree valuesareonlyconsideredCHDifstoredtogetherwiththePAN.Itispermittedto storecardholderdata,andthereareadditionalPCIDSSrequirementswhichapplyitthatcase.ThestandardalsorequiresrenderingthePANunreadablewhich

isubiquitouslyachievedbymaskingallbuttheBIN(firstsix)andthelastfour digitsoftheaccountnumber.Requirement3.3ofthePCIDSSstandardprohibitstodisplaymorethanthesedigitstoanyonebutpersonnelwithalegitimate businessneed.

Sensitiveauthenticationdataisdefinedasfulltrackdata(includingtrack1, 2and3),CVV2data,thePINandthePINblock.Unlikecardholderdatathat canbestored,itisforbiddentostorethesensitiveauthenticationdataincluding stronglyencryptedform.

8.1.2LevelsofComplianceandAssessmentProcess

ThePCIDSSstandarddoesnotdefineany”levelofcompliance”andanentity eithercompliesordoesnotwithPCIDSSrequirementsbutthereisadistinction madeformethodstoassessandcertifythecompliance.Amerchant,processor, institutionoranotherentitycanfollowoneofthetwopathstocertifyitscompliance:anauditbyaQualifiedSecurityAuditor(QSA)oracompletionofa Self-AssessmentQuestionnaire(SAQ).

UponcompletionofaSAQ,themerchantorprocessorauthorizedpersonnel signanAttestationofCompliance(AOC)documentwhotherebycommittoboth levelsofcomplianceasstatedintheattestationandtheactionplantobecome fullycompliantincasecertainrequirementsarenotfullymet,asneeded.

UponcompletinganauditbyaQSA,theauditorpreparesaReportofCompliance.Itmaycontaincommittedactionplanswithspecificdatesforfullcomplianceaswellaswell-definedcompensatorycontrols.

AQSAcanalsobeinvolvedincompletinganSAQincasetheentitythat undergoesself-assessmentsodesires.

Paymentschemestypicallygroupentitiesinvolvedinprocessingintoseveral groupsor“levels”.TheselevelsarenotpartofthePCIDSSstandard,anddespitewidelyaccepteddefinitionsaresetbyschemesattheirowndiscretion.The highestlevelofPCIDSScomplianceisusuallydubbedlevel1andrequiresan annualauditbyaQSAwhilesomelowerlevelsmayrequireinitialQSAaudit followedbyself-assessmentorevenrequireannualSAQsonly.

Schemestypicallyassignlevelsbasedontheannualvolumesofcard-present andcard-not-presenttransactionsprocessingwhichcanbecountedregardless ofthepaymentscheme(e.g.,Visacanrequestthefullvolumeofprocessing includingMasterCard,AmericanExpress,etc.,toassignthelevelofrequired compliance).Itisalsotypicaltotolerateabiggernumberofcard-presenttransactionsversusamuchsmallernumberofcard-not-presenttransactionsforthe samelevelofcompliancesothattheprocessingvolumesoftensofthousandsof e-commercetransactionsrequireadherencetothesamerulesastheprocessing ofhundredsofthousandsofcard-presenttransactions.

Entitiesarerequiredtoperforminternalandexternalvulnerabilityscansat leastquarterlyandaftereverymajorchangeinthesolution.Internalscanscan

bedonebyaninternalteamwhileexternalscansaretobeperformedbyan ApprovedScanningVendor(ASV).AlthoughtherequirementispartofthePCI DSSQSAevaluationitcanalsoberequiredinsomecasesinvolvinganSAQ(see section8.1.3.

TheSAQs,AOCsorROCswithASVscanreportsasrequiredandaccording tothespecificsituationaresubmittedtoprocessors,acquirersorcardschemes fortherequiredcompliancereviewandconfirmation.

8.1.3Self-AssessmentQuestionnaires

SAQsdependonanentity’sspecificsanditscardprocessingenvironment.Most SAQtypesweredefinedforspecifictypesofmerchantsandarefocusedonthe requirementsrelevantforthosemerchanttypes.

MostSAQtypesdonotallowanycardholderdatastorageinmerchants’ systems:merchantsthatstorecardholderdataautomaticallyrequiretheSAQD questionnairecoveringthelargestscope.

Card-not-presentmerchantsshoulduseeitherthelighterSAQA/SAQA-EP questionnairesorthefullerSAQDforMerchantsquestionnaire.Card-present merchantscanberequiredtoperformself-assessmentbasedonSAQB/SAQBIP/SAQC/SAQC-VT,SAQP2PEquestionnairesordefaulttothefullSAQD forMerchantsquestionnaire.

SAQA questionnaireappliestonon-face-to-facemerchantswhohavefullyoutsourcedtheirprocessingtoaPCI-DSScompliantentityandperformno cardholderdataprocessing,transmissionorstorage.

SAQA-EP questionnaireappliestomerchantswhodidlikewisebutpossessa websitethatcanimpactapaymenttransactionsecurity

SAQB questionnaireappliestocard-presentmerchantsonly,utilizingimprintersorhavingadial-upconnectiontotheirprocessor.

SAQB-IP questionnaireisdesignedforcard-presentmerchantswhoseterminalsarePCIPTSapprovedandconnectedtotheprocessorviaanIPconnectionbutstorenocardholderdata.

SAQC questionnaireappliestocardpresentmerchantsusingpaymentsystems connectedtotheInternet.

SAQC-VT appliestomerchantswhokeyincards(inacard-presentenvironment)intoavirtualterminalprovidedbyathird-partyprocessor.

SAQP2PE questionnaireisdesignatedforcard-presentmerchantshavinga PCI-SSClistedfully-managedhardwareP2PE–compliantterminalsystem.

SAQD themostcomprehensivequestionnaireofthefamily,existsintwoflavors:SAQDforMerchantsandSAQDforServiceProviders.Entities storingcardholderdataaretoself-assessusingthecorrespondingSAQD questionnaireregardlessofthecardpresenceintheirtransactions.

8.1.4PCIDSSPrinciples

PCIDSSstandardlistssixcoreprinciplessubdividedintorequirementsthat, inturn,containmultiplenestedsub-requirementsincludingwell-definedtesting andassessmentproceduresandcompliancecriteria.Bothbestpracticesandthe detailedsub-requirementsarelistedinthemostrecentPCIDSSstandard.However,asthestandardisstructuredaroundthesecoreprinciplesthereisvalueina top-downreviewoftheprinciplesandrequirements.

RegardlessofthesecurityaspectdefinedinthePCIDSSstandard,ithasto besecurelydeployed(useraccessrightsrestricted,firewallsconfigured,antivirus installed),anychangestoitmusthaveadocumentedbusinessreason,followa well-definedprocedureandleaveapapertrail(accessrequestprocess,firewall configurationprocess,antivirusdefinitionsupdateprocess)aswellastobeperiodicallyassessedforcomplianceandvulnerabilities(bymeansofscanningand disablinginactiveuseraccounts,performinginternalandexternalvulnerability andpenetrationtests,reviewingfirewallconfigurations,etc.).

BuildandMaintainaSecureNetworkandSystems

Theprincipletranslatesintotworequirements:“Installandmaintainafirewall configurationtoprotectcardholderdata”and“Donotusevendor-supplieddefaultsforsystempasswordsandothersecurityparameters”.

Therequirementtomaintainafirewallconfigurationtoprotectcardholder data(Requirement1)containssomesub-requirementscoveringkeynetworksegmentswhichshouldbeseparatedbyfirewalls,processesforjustifying,documenting,reviewing,approvingandrevisitinganychangeinfirewallconfiguration,requirementsforpropersynchronizationofrouterandfirewallconfiguration acrossdifferentinstancesandnetworksandrequirementsforportabledevices connectedtothecardholderdataenvironment.

Therequirementtonotusevendor-supplieddefaultsforpasswordsandother parameters(Requirement2)containssomesub-requirementswhichinaddition totheobviousdetaileddescriptionofthegeneralrequirementalsoprescribethat eachhostonthenetworkshouldprovideasinglemajorservice(e.g.,NTPor DNS)andthatallotherservicesonthathostshouldbedisabled.

ProtectCardholderData

Thisprincipletranslatesintotworequirements:“Protectstoredcardholderdata” and“Encrypttransmissionofcardholderdataacrossopen,publicnetworks”.

Therequirementtoprotectstoredcardholderdata(Requirement3)contains severalsub-requirements.Firstandforemost,sensitiveauthenticationdata(see section8.1.1)cannotbestored.Second,cardholderdatastoringmustbekepttoa minimumnecessary,includingbothwell-definedandwell-maintainedretention policiesaswellashashing,truncatingorencryptingthePAN.Finally,foranyencryptionschemeusedtheencryptionkeysmustbesecurelyhandledandrotated inatimelymanner.

Therequirementtoencryptdatatransmissionacrosspublicnetworks(Requirement4)prescribesencryptingthePANdataduringtransmissionusing strongcryptographicmethodsasdefinedinPCIDSSglossaryandnevertransmittingafullunencryptedPANusingsuchmeansasSMSorinstantmessenger. Thelatterrequirementapplieslesstosystemsandmoretoworkingprocessesof peoplesupportingandmaintainingthesesystems.

MaintainaVulnerabilityManagementProgram

Theprincipletranslatesintotworequirements:”Protectallsystemsagainstmalwareandregularlyupdateanti-virussoftwareorprograms”and“Developand maintainsecuresystemsandapplications”.

Therequirementtoprotectsystemsagainstmalware(Requirement5)prescribesdeployingandregularlyupdatingproperanti-virussoftwarethatcannot bedisabledbyendusers.

Therequirementtodevelopandmaintainsecuritysystemsandapplications (Requirement6)containssomesub-requirementspertainingtotwoprocesses.It prescribestracking,prioritizingandpatchingvulnerabilitiesinthird-partyvendor software,includingtimelinesforsecuritypatches.Italsogoesintogreatdetails describingsecuremethodsforcustomcodeandin-housesoftwaredevelopment, maintenanceanddeployment.

TocomplywithPCI-DSSrequirementsforcustomcode,itsdevelopmentand testingshouldbeproperlyseparatedfromtheproductionenvironment.Special attentionshouldbepaidtodeveloperandtestingaccountsneededtobedisabled priortoproductiondeployment.Furthermore,thecodemustundergoamandatorysecuritycodereviewbyatrainedreviewerwho,inturn,shouldkeepupto datewiththemostrecentsecurecodingpractices.

ImplementStrongAccessControlMeasures

Theprincipletranslatesintothreerequirements:“Restrictaccesstocardholder databybusinessneedtoknow”,“Identifyandauthenticateaccesstosystemcomponents”and“Restrictphysicalaccesstocardholderdata”.

Therequirementtorestrictaccesstocardholderdataonaneed-to-knowbasis (Requirement7)alsorequiresthatthedefaultlevelofaccesstocardholderdata isalways“denyall”.

Therequirementtoidentifyandauthenticateaccesstosystemcomponents (Requirement8)prescribeshavingauniqueidentifierassignedtoeachuser.It prohibitstheuseofgroupaccountsandsharedpasswords,restrictsdirect(asopposedtoviaanapplication)accesstodatabasewithcardholderdatatodatabase administratorsandrequiresallnon-consoleadministrativeaccesstobeprotected withamulti-factorauthentication.Therearealsosomesub-requirementsfor passwordpolicies,removalofinactiveaccountsandlock-outsofinactiveuser sessions.

Therequirementtorestrictphysicalaccesstocardholderdata(Requirement 9)coversthreemajorareaswithitssub-requirements.Afacilityentrycontrol tolimitandmonitorphysicalaccesstosystemsinthecardholderdataenvironmentisrequiredaswellastherulestoidentifyandauthorizevisitorstothefacilities.Anothersetofsub-requirementscoversclassification,storage,shipping anddestructionofmediathatcontainscardholderdata.Finally,therearesubrequirementstoprotectdevicesinteractingphysicallywiththecardfromtampering,includinginventory,separationofaccessandpropertrainingofhandling employees.

RegularlyMonitorandTestNetworks

Theprincipletranslatesintotworequirements:“Trackandmonitorallaccessto networkresourcesandcardholderdata”and“Regularlytestsecuritysystemsand processes”

Therequirementtotrackandmonitoraccess(Requirement10)prescribes creatingandmaintaininganaudittrailofuseractivitywhichshouldalsobeperiodicallyreviewedforanysuspiciousactivity.

Therequirementtoregularlytestsecuritysystemsandprocesses(Requirement11)demandsregularscanforunauthorizedwirelessaccesspointsandnetworks,quarterlyinternalandexternalnetworkscansforknownvulnerabilities, andpenetrationtests.

MaintainanInformationSecurityPolicy

TheprincipleislistedasRequirement12inthePCIDSSstandard.Therequirementisdefinedas“Maintainapolicythataddressesinformationsecurityfor allpersonnel”andmandatesthecreationandmaintenanceofaninformationsecuritypolicypublishedtoallpersonnel,includingfull-timeandpart-timeemployees,contractorsandresidentconsultants.Therequirementalsomandatesa periodicriskassessmentprocessandanincidentresponseactionplan.

8.2PCIPaymentApplicationsDataSecurityStandard (PCIPADSS)

PCIPADSSappliestosoftwarevendorsdevelopingpaymentapplications.Accordingtostandard’sdefinitionapaymentapplicationisonethat“stores,processesortransmitscardholderand/orsensitiveauthenticationdata”.

ThekeydifferencebetweenPCIPADSSandPCIDSSisthattheformer appliestoanindividualapplicationwhilethelattercoverstheentiresolutionor evenfullscopeofthecompanysystems.

ItispossibletohaveanapplicationthatisfullyPCIPADSS–compliantbut deployedandusedinsuchamannerthatitfailsPCIDSSrequirements.Conversely,itispossible,thoughcertainlynotadvisabletouseanon-compliantpaymentapplicationbuttocomplywithPCIDSSstandardbydeployingcompensatingcontrols.

OnesuchmethodisactuallydescribedinthePCIPADSSstandard:aterminalapplicationnotPADSS–compliantonitsownmayresideonadevicethat complieswiththePINTransactionSecuritystandardandthereforemaycomplywithPCIDSSthroughthecombinationofapplicationandhardwaresecurity controls.

ThePCIPADSSstandardusesthesamecardholderandsensitivedatadefinitionsasPCIDSSstandardandhasasimilarassessmentprocess.

DuringaPCIDSSaudithavingPCIPADSScertificatesforallrelevantapplications(onesthatinthesolutionstore,processortransmitCHDorSAD)significantlyshortensthecertificationprocessastheassessordoesnothavetolookinto eachindividualapplicationhavingreceivedtheresultsofanassessmentalready performed.

ItfollowsthathavingaPCIPADSScertificationishighlyrecommendedto anyvendorofpaymentapplications.

8.2.1PCIPADSSRequirements

ThePCIPADSSstandardcontains14requirementsfurthersubdividedinto lower-levelrequirementsandaccompaniedwithtestingproceduresandguidance.PCIPADSSrequirementsarealsoexplicitlymappedtocorresponding PCIDSSrequirements.

Requirement1—“Donotretainfulltrackdata,cardverificationcodeorvalue (CAV2,CID,CVC2,CVV2),orPINblockdata”

Requirement1isnottoretainanysensitiveauthenticationdata,namelyfulltrack data,CVCs,orPINblockdata.Therequirementmakesexceptionforsoftware madeforissuers.Ifthesoftwarehasotherintendeduses,itshouldeithernever storeorverifiablydeletetheSADafterauthorization.

Therequirementalsodemandssensitiveauthenticationdataremovalduring thesoftwareupgradeprocessincasesuchdatawasstoredbythepreviousversion ofthesoftware.Finally,therequirementliststhemeasuresthatshouldbetaken incasesomeauthenticationdatamustbestoredfordebuggingortroubleshooting purposes.

Therequirementsaimtoensurethatthemostsensitivedataisprotectedfrom possiblecompromisebyitsabsencefromtheapplication.

Requirement2—“Protectstoredcardholderdata”

Requirement2demandsthecardholderdataprotection.Thevendormustprovide guidancetotheircustomersregardingdatacleanupaftertheretentionperiodexpiration,makingsurethePANsarenormallymaskedandthefullvaluesareonly visibletopersonnelwithactualbusinessneedtoaccessthem,andrenderPAN unreadableanywhereitisstored.

Theapplicationmustprotectcryptographickeysitusestosecurecardholder dataandensurenecessaryframeworkofkeygenerationandmanagementprocessesaswellasprovidemechanismstoreliablyrenderobsoletekeysirretrievable.Althoughmanyofthemeanscanbeimplementedinsoftware,usingsuch securedevicesasHSMswhereverpossibleisusuallyabetterwaytosupportthe requirements.

Therequirementprovidesframeworktoprotectcardholderdatafromcompromiseifithastobestoredintheapplication.

Requirement3—“Providesecureauthenticationfeatures”

Requirement3describessecureauthenticationandauthorizationfeaturesofthe softwaresuchasindividualuseraccounts,passwordpolicies(includingcomplexityandlengthrequirementsandhistory),securepasswordstorage,inactive sessionexpiryanduserlockoutmechanisms.Therequirementprescribesfinegrainedaccessmanagementwithintheapplication,includinglimitingaccessof useraccountstotheminimumnecessaryapplicationfeatures.Inaddition,default accounts,groupaccountsorgenericaccountsareprohibited.

Therequirementaimstodefinerequirementsforuseraccessandauthorizationfollowingtheindustrybestpractices.Itshouldalsobeconsideredinconjunctionwithrequirement4,speakingaboutlogging:ifeachuserisidentified individuallyandauthenticatedinareliablemanner,thenloggingfullactivityof eachusercreatesanaudittrailthatisveryusefulforforensicsincaseofacompromise.

Requirement4—“Logpaymentapplicationactivity”

Requirement4describesnecessarylogstheapplicationmustbecapableofwriting.Therequirementistologalluseractivity,includingfailedandsuccessful attemptstoaccesscardholderdata,allactionsofapplicationadministrators,and anyattempttoaccessauditlogsthemselvesoralterloggingmechanisms.

Inconjunctionwithrequirement2(protectionofcardholderdata)andrequirement3(userauthenticationfeatures)therequirementensurestheavailabilityofanaudittrailincaseausertrieseithertoaccesscardholderdatawhenthey reallyshouldnotbeaccessedortotamperwithevidenceofsuchaccess.

Requirement5—“Developsecurepaymentapplications”

Requirement5speaksaboutthebestpracticesconcerningtheapplicationdevelopmentprocess.Accordingtoit,theapplicationdevelopmentmusttakeintoconsiderationthefullscopeofPCIDSSrequirementsandtheprocessesmustbein placetoensurethecodeavoidscommoncodevulnerabilities.Securitytraining, securityreviewsofeachapplicationversionandcodereviewsarealsorequired.

Inadditiontomakingsurethecodeisinitiallywritteninasecureway,therequirementelaboratesthewayitshouldbekeptsecureincludingtherequirements forsourcecontrolandversionmanagementensuringtheintegrityandachange managementprocessthatmakessurenounauthorizedchangecanbemadeinto theapplication.

Thesub-requirementsunderrequirement5givespecialconsiderationtothe waySADisstoredinmemorydemandingthatisexplicitlydocumented.

Finally,therearerequirementsfortestdata:nolivePANsmusteverbeused intestenvironmentsand,conversely,allthetestdataandtestaccountsmustbe removedfromtheapplicationpriortoitsdeploymentintoproduction.

Requirement6—“Protectwirelesstransmissions”

Requirement6coversminimumstepsthatmustbetakenincasetheapplication useswirelesstransmissionsincludingthecaseswhentheapplicationisnotexplicitlydesignedforusewithawirelesscommunicationsnetwork.Applications thatareexplicitlydesignedforwirelesstechnologyorarebundledwithitmust havevendordefaultschangedandmustusebestpracticesforauthenticationand encryption(e.g.,WEPisexplicitlyforbiddeninthestandard).

Incasetheapplicationwasnotexplicitlydesignedforwirelesstechnologybut sincecanbepossiblyusedwiththewirelessinfrastructure,theimplementation guideprescribedbythestandardmustcontaindetailsonsecurityofwireless networks.

Requirement7—“Testpaymentapplicationstoaddressvulnerabilitiesand maintainpaymentapplicationupdates”

Requirement7prescribessecuritytestingofthepaymentapplicationbut,more importantly,outlinesthevulnerabilityandriskmanagementprocesses,including arequirementoftimelysecuritypatchingofthesoftwareanddocumentationof securityvulnerabilitiesinreleasenotes.

Whilerequirement5makessurethepaymentapplicationiswrittenwithsecurityinmindandnomaliciouscodeispurposelyinjectedintosoftwareversions,

requirement7makessuretheapplicationstayssecure:theapplicationisexplicitlytestedforsecurityandincaseanissueisfounditisfixedwithduehaste.

Requirement8—“Facilitatesecurenetworkimplementation”

Requirement8describesthewaytheapplicationmustmakesureitdoesnotinterferewithsecurenetworkimplementationaccordingtoPCIDSSstandard.For instance,theapplicationmustnotrequireantivirustobeturnedofftofunction, relyonanon-securesystemprocessoruseaportutilizedbyastandardsecurity protocolinthePCIDSSenvironment.

Requirement9—“CardholderdatamustneverbestoredonaserverconnectedtotheInternet”

Requirement9isperhapsoneofthestandardshortestonesintermsofsub-items. Beyondtheself-describingtitle,therequirementgoesontoelaboratethatifthe applicationrequiresInternetconnectivity,itmustallowanyserver-storingcardholderdata(e.g.,databaseserver)tobedeployedinadifferentnetworksegment.

Requirement10—“Facilitatesecureremoteaccesstopaymentapplication”

Requirement10dealswithremoteaccesstothepaymentapplicationfromoutsideofthecustomerenvironment.Itprescribesmulti-factoraccesstoanypersonnelaccessingtheapplicationeitherthevendor’sorthecustomer’sones.Itgoes ontodetailrequirementsinthecaseofremoteaccesstocustomersystemsby vendorsforsupportandupdatepurposes.Forexample,ifdownloadstothecustomerenvironmentwithoutusingofaVPNarerequired,thenecessaryremote accessmustbeturnedonimmediatelybeforeandturnedoffimmediatelyafter thedownload.

Requirement11—“Encryptsensitivetrafficoverpublicnetworks”

Requirement11doesnotexplicitlyprescribetheuseofTLSovervarioustypesof networksbutmentionsitinitssub-itemsandtheenclosedguidanceseveraltimes. Therequirementdemandsthatanysensitivedataisencryptedintransmission and,furthermore,thatifsuchdataasPANsisdistributedoverend-userchannels (suchasemails),strongcryptographyisusedtoprotectit.

Requirement12—“Secureallnon-consoleadministrativeaccess”

Requirement12mandatesstrongencryptionofanyadministrativeaccessnotvia console.Forinstance,toquoteanexamplefromthestandard,telnetisnottobe usedwhileSSHistobeusedinstead.Furthermore,multi-factorauthentication isrequiredforallthepersonnelwithnon-consoleadministrativeaccesstothe application.

Requirement13—“MaintainaPA-DSSImplementationGuideforcustomers,resellers,andintegrators”

Requirement13mandatesthatavendorshouldmaintainadetailedguideonthe secureimplementationoftheapplicationinthePCIDSScompliantenvironment.

Requirement14—“AssignPA-DSSresponsibilitiesforpersonnel,andmaintaintrainingprogramsforpersonnel,customers,resellers,andintegrators”

Requirement14mandatesrecurringtrainingprogramsforalltheactorsmentionedinthetitlewithtrainingandtrainingmaterialsreviewtobeconducted annually.

8.3KeyManagementwithHardwareSecurityModules (HSMs)

8.3.1HardwareSecurityModules(HSMs)

Hardwaresecuritymodulesprovidepaymentindustryactorswithahighlevelof securitybyperformingallencryption-relatedoperationsinaprotectedenvironment.HSMsareequippedwithavarietyofsensorsandareabletodestroytheir contentsifanattemptofunauthorizedaccessismadeorifthedeviceisbeing tamperedwith.Forexample,HSMshavebuilt-invibrationsensorsthatwould reactifanattempttoremovetheHSMfromtheserverrackismade,andthere arespecialproductlinesofhardwaresecuritymodulesforseismicallyactiveareas.

AllsensitivedatainsideanHSMisprotectedbyoneormoremasterkeys, referredtoasLocalMasterKeyor LMK orMasterFileKeyor MFK.Multiple LMKscanco-existinanHSMsimultaneously.Toenableadministrativeaccess toanHSMforgenerationofother,derivedkeys,anLMKiswrittenintoatleast twosmartcardswhich,iflost,renderthespecificLMKslotunusable.

AtleasttwophysicalkeysaretypicallyusedtoswitchanHSMintotheadministrationmodeandtemporarilyturnoffsomeofitsprotectionmechanisms.

EventheowneroftheHSM,onceitisproperlydeployed,islimitedinhis controlofthemoduleincomparisontoastandardserveroranappliance.Ifafinancialinstitutionsomehowlostallofit’ssmartcardswithanLMKcomponent, eventherelativelystraightforwardprocessofrelocatingahostingfacilitywould requireinvolvementofmilitaryforcestrainedindisarmamentofundetonated munitions(i.e.,peoplewhoareabletomoveanobjectVERYcarefully).

Asarule,HSMsutilizetwotypesofkeys—dataencryptionkeys,usedto calculatecardvalidationvalues,pinverificationvalues,decipherandtranslate PINblocksetc,andkeyencryptionkeys(KEK),usedsolelytoencryptandsecure dataencryptionkeys.

TheKEKsthemselvesarestoredoutsideoftheHSMunderLMKandthe dataencryptionkeysare,inturn,encryptedusingKEKandthenusedtoencrypt ordecryptthedata.AsLMKsarekepthighlysecure,bothKEKsunderLMK anddataencryptionkeysunderKEKsareallowedtobestoredinadatabaseor onafilesystemexternaltotheHSM.

Toillustratetheprinciple,considertheCVVvalidationscenario.TheCVK isencryptedusingtheLMK.Theresultingvalue,CVKLMK,isstoredexternally inadatabaseandisassociatedwithacertainPANrange.Onceatransaction arrivesattheissuerhost,theCVVdatafromTrack2discretionarydatasubfield istransmittedtotheHSMalongsidetheCVKLMK.TheHSMfirstdeciphersthe actualCVKandthenusesitsvaluetovalidatetheCVV.

Asforamorecomplicatedscenario,consideracaseofPINtranslation whenthereisanincomingencryptedPINblock(EPB)encryptedwithanacquirerworkerkey(AWK1)andtheprocessingplatformhastosendthePIN blockunderanotherworkerkey(AWK2)tothepaymentscheme.Inthiscase, bothworkerkeysarestoredunderLMKinadatabaseexternaltotheHSM andtheinvocationofthePINtranslationfunctionhasthefollowingparameters:EPBAWK1,AWK1LMK,AWK2LMK.Theoutputofthetranslationoperation isEPBAWK2 whiletheunencryptedvaluesofbothworkerkeysandtheEPBdo notexistoutsideoftheHSM.

8.3.2HSMKeysandAlgorithms

Table8.1 summarizessomeofthekeytypesthatarementionedaboveandbelow, includingalternativeterminology.

Variousscenariosthatoccurinpaymentindustryutilizedifferentencryption algorithms.Foracquiringofcardpayments,however,onlyalgorithmsrelevant toPINtranslationrequiretheHSMsuseandunderstandingand,consequently, onlytheyarecoveredherein.

ToprotectPINblocksandPINkeys,the3-DESalgorithm(seesection12.2) withsingle,dualandtriple-lengthkeysisused1.AsthePCIDSSstandardin itsdefinitionof“strongcryptography”mandatestheminimumeffectivekey strengthof112bits,thesingle-lengthDESkeysarenotPCIDSS–compliant andshouldnotbeusedinproduction.Theyareeasiertomanageanduseduring theirdevelopmentandtestingand,ifatall,shouldonlybeutilizedduringsuch activities.

Therefore,validkeysarebinarystringsoflength8,16or24.Itiseasytosee thatasingle-lengthkeycanbe“disguised”asadouble-ortriple-lengthkeyby repeatingthefirst8bytes.However,HSMsdetectandprohibittheuseofsuch keysinsecureproductionmode

1Thelattertwooptionsaresometimesalsodenotedas2TDESand3TDES,correspondingly.

SinceDESisablockcipherwith8-byteblocksize,keyscanbeencryptedby otherkeyswithoutpadding.AnHSMmayexportthekeysinencipheredform usingdifferentformatssuchaskeyblocksundervariousstandardsorusingproprietaryrepresentationssometimesreferredtoas“keyschemes”.ThewidelyacceptedANSIX9.17standardoftenassumedbydefaultrequiresjustthe3-DES encryptionwiththeappropriateKEK.

8.3.3VariantsandKeyBlocks

Tomakesurekeysareproperlysecureandlessvulnerabletoattackstheiruse mustbeappropriatelylimited.Naturally,akeythatisneverusedisakeythat isveryhardtocompromise.Awideruseofakeybeyondthenecessarywould increasepossiblepointsofattackonitaswellasallowanattackertogather moredataforknown-plaintextattacks.Inasense,keysformahierarchy:the

Thekeyisusedtoderiveand encryptothersensitivekeys. Besidesbeingstoredinsidethe HSM,itisusuallystoredon externalmedia(smartcards)as twoormoreseparatecomponents. Itisonlyusedfortheencryption ofkeysandneverisforthe encryptionofactualdata.

Azonemasterkeyisusedto establishmutualtrustinatrust zone.Itisusedfortheencryption ofkeysandnotusedforthe encryptionofdata.

Thekeyisusedtoencryptand decryptaPINinaPINblock.

Itisagenericnameofan encryptionkeyusedtoencrypt genericdata.

masterkeyresidesatthetopofit,keyencryptionkeysarefoundunderitand workedkeysusedtoencryptdataareatthelowestlevel.Obviously,anattacker hasmoreopportunitiestogathervaluesforanattackonakeyusedtoencrypt data.Ifthekeyisonlyusedforthatpurpose,itscompromiseisremediedbya swiftrotationofdataencryptionkeys,whichiseasytoperformiftheKEKsare stillintact.However,ifthekeyisalsousedasKEK,thedamagewillbemuch moreprofound.

Tolimitthekeyusebeyondtheiroriginalpurposesomeproprietaryrepresentationsinvolvedtheapplicationofa variant whenapre-definedvalueisXOR-ed withthekeyduringits3-DESencryption.Sinceonebitofeachbyteofa3-DES keyisusedforparity,anattempttouseavariant-encryptedkeywhenanANSI X9.17keyisexpectedislikelytoresultinaparitycheckerror.Asitisstilltheoreticallypossiblethatavariantkeywouldpassparitycheckandwouldbeused foranadditionalpurpose,themethodisdeprecatedandphasedouttobereplaced with keyblock.

Inthecaseofakeyblock,akeyiswrappedintoastructureofdatacontaining informationaboutitspurpose,itslength,theencryptedkeyitselfplusasignature, usuallyastronghash,sometimesreferredtoas keyblockauthenticator.Inthis manner,akeypurposemaybelearnedfromtheheader,andsecuredeviceswill notpermittheuseofthekeybeyondwhatisdefinedinthekeyblock.Thestructureofthekeyblockisshownin figure8.1

Figure8.1:Structureofakeyblock

8.3.4TrustZones

InbusinessscenarioswhentwoHSMsneedtoshareakeyfordataencryption (forexample,inPINtranslation,whenanencryptedPINblockisre-encrypted byanHSMduringtherelaybetweenpaymentnetworksegmentsorduringthe exchangeofCVKsbetweenissuersandschemesforstand-inprocessing),zone notionisused.Aswithlocalkeys,thereisseparationbetweenkeyencryption keysanddataencryptionkeys.

TheprocessofestablishingatrustzonebetweenHSMsincludestwosteps. First,aZoneMasterKeyorZMKissecurelysharedbetweentwoHSMs.The typicalprocessisusuallyasfollows(anypartycaninitiateit):

1.PartyAkeycustodians(seesection8.3.7)generateaZMKintheformof clear-textcomponents.

2.KeycustodiansofPartyAsecurelycombinethecomponentstogenerate aZMKunderLMKofPartyA’sHSM.

3.KeycustodiansofPartyAsecurelyhandovertheirrespectivekeycomponentstokeycustodiansofPartyB.

4.KeycustodiansofPartyBsecurelycombinethecomponentstogeneratea ZMKunderLMKofPartyB’sHSM.

Atthispoint,bothpartiespossessasharedKEKwhichcanbeutilizedto exchangeworkerkeys(inthecaseofPINtranslation,theyaredenotedasAWKs orZPKsoracquirerworkerkeysorzonePINkeys).

Uponestablishingthesharedsecret,thepartiescanusetheHSMtogenerate suchakeyunderLMKandZMK.Thekeyasitisencryptedusingastrong cryptographicmethodcanbesentoverapublicnetwork(forinstance,emailed).

TheprocessofgenerationandexchangeofZPKsusuallyhappensasfollows (itcanbeinitiatedbyanypartyregardlessoftheinitiatorinthepreviousstepand regardlessofthesenderandthereceiveroftheactualpinblock):

1.PartyAkeycustodiansgenerateaZPKinencryptedformunderLMKand ZMK.TheformerisusedbypartyAhostsystemsandiseitherusedto encryptEPBsoutgoingtoPartyBordecryptEPBsincomingfromparty Bdependingonthedirectionofthedataflow.

2.PartyAkeycustodiansretaintheZPKunderLMKandsendtheZPK underZMKtopartyB.

3.PartyBkeycustodiansimporttheZPKunderZMKintopartyB’sHSM whichyieldsZPKunderLMKofpartyB.ThekeyisusedbypartyB hostsystemstoeitherencryptoutgoingEPBsinthedirectionofpartyA ordecryptincomingEPBsfrompartyAdependingonthedirectionofthe dataflow.

8.3.5KeyComponents

Asmentionedpreviously,zonesecrets(thekeyencryptionkeysknowntoparties withinatrustzone)havetobegenerated,deliveredanddeployedusingcleartextdataduetothefactthatamutuallysharedsecretisonlyestablishedbetween theparties.Thissensitiveclear-textdataexchangeisperformedaccordingto theprinciplesofmulti-partysplitknowledge.Severalofficersofthefinancial institution,usuallyatleastthree,usetheHSMaspartofakeyceremonyto generateclear-textcomponentsofafuturekey(seesection8.3.7)each.

Theclear-textcomponentsarebinarystringstypicallyrepresentedinhexadecimalformatandwrittendownphysicallyonspeciallydesignedforms.The lengthofthesecomponentsisidenticaltothelengthofthefuturekeyandis32 incaseofdual-lengthand48incaseoftriple-lengthkeys.

Upongeneratingclear-textcomponents,theyarereimportedintotheoriginatingHSMtoformaZMKundertheLMKofthesenderandtogenerateakey checkvalueofthefullkey.

Thekeycustodiansoftheoriginatinginstitutionsendthecomponentsalongsidethekeycheckvaluetothekeycustodiansoftherecipientinstitutionusing specialprecautionsusuallyintamper-evidentenvelopesviathreedifferentdeliverymethodsandondifferentdates.

ThenthereceivingpartyusesitsHSMtorecombinethekeysintoafully functionalZMK.Whiletheproceduresaroundtheprocessaresomewhatelaborateandinvolvesignificantpaperwork,themathematicalprinciplebehindthe keyimportfromclear-textcomponentsissimple:theyareXOR-edtogetherto formasinglekey.TheimportprocesstypicallyproducesaZMKunderLMKof therecipientandalsogeneratesaKCVwhichiscomparedtotheoneenclosed withthedeliverytoconfirmthattheprocesswascompletedproperly.

8.3.6PINSecurityRequirements

ToensurethatPINvaluesaredulyprotected,cardschemeshaveimposedsecurityrequirementsanddefinedtestingprocessesfortheserequirements.Withtime asthePCIcouncilcaughtup,schemesbeganagradualtransitiontoPINSecurity Requirementswiththelatestversion(asofthiswriting)nowbeingversion3.0.

8.3.6.1GeneralPrinciples

CardschemerulesmakecleardistinctionbetweenentitiesvalidatingPINsand thoseonlyhandlingthemintransit.Forinstance,apure-playacquirerisanonvalidatingentityunlikeanissuerwhohastovalidateonlinePINs.

Allhardwarethathandlesclear-textPINvaluesmustbetamper-resistant.The hardwareincludesATMs,HSMsandPINpads,i.e.,eitherdevicesthatinteract withthecardholderduringPINentryorperformPINtranslation.

Thedataflowofaninstitution’ssystemsmustbebuiltinamannerallowing noPINblockslogging.Store-and-forwardschemesarealsotypicallyprohibited butcanbeacceptedinthecaseofadditionalsecurityprovisionsmadetoensure safeEPBsstorage.

Thekeysmustbegeneratedusingarandomnumbersgeneratorsatisfying statisticaltestsofFIPS140-2(FederalInformationProtectionStandard)orits equivalentandtheproceduresaroundthekeygenerationshouldensurethatkey compromiseisonlypossiblethroughthecollusionoftwoormoreindividuals.

Similarrequirementsareplacedontheaccesstokeysandkeycomponents. Thegoverningprinciplesaredualcontrolandsplitknowledge.Dual(ormultiparty)controlensuresnosinglepersoncangainaccesstoaprotecteditemsuch asaclear-textkey,andsplitknowledgemeansthatnosingleindividualpossesses enoughinformationtoderiveanactualkey.

IfthekeyisstoredonphysicalmediaoutsideanHSMoristransported,it mustatalltimesremainunderthesupervisionoftheauthorizedindividualor lockedinasecuretamper-evidentcontainer.Usually,allkeysarekeptintamperevidentenvelopesinsidesafesthatonlyauthorizedindividualscanopen.

Thekeyloadingprocessmustbedoneinacontrolledmannerensuringa properpapertrailofactionsperformedandindividualsinvolvedandinaproper seclusionincaseclear-textcomponentsareused.Aproperkeyloadingprocess alsorequiresdual-ormulti-partyhardwarecontrol.Itisalsocrucialthatthe keysarevalidateduponload(inmostcasestheconfirmationoftheKCVshould suffice).

Besidesbeingcompliantwithnecessarystandardskeysmustbeuniqueand sufficientlylong(asmentionedabove,atleastdual-lengthatthetimeofwriting) andeachmustbeusedforasinglepurpose(i.e.,aZMKcannotbeusedfor anythingbutencryptionofZPKswithinawell-definedtrustzone)

Theentirelifecycleofbothkeysandequipmentmustbeproperlyloggedand documented.Atanygivenmomentapapertrailmustallowtracingakeyora pieceofequipmenttoitssource.

Thekeysmustbesecurelyadministered:accesstokeysmustbeloggedand limitedtothechosenfewindividuals,backupkeysmustbestoredsafely,obsolete keysmustbeproperlydestroyed.Samerequirementsapplytotheequipmentthat handlesthePINs.

Likewise,accessequipmentpriortodeploymentmustbeloggedanddecommissionedequipmentmustundergotheremovalofsensitivedataandespecially thekeyvalues.Activeequipmentmustalsobeprotectedfromphysicalaccess whereapplicable:whileATM,obviously,isaccessibletothepublic,HSMs, whendeployedinserverrooms,aretypicallysetupinaseparatecagewithadditionallocksandextrasecuritycameras.

ItisusefultoseetheprinciplesofPINsecuritybylookingatthePCIPINSe-

severalchapterscoveringtransactionprocessingingeneral,symmetrickeydistributionusingasymmetrickeysandrequirementsforkey-injectionfacilities.

Eachchapterisdividedintoseveralcontrolobjectivesfurthertranslatedinto specificrequirements.Thestandardprovidesspecificreferencesandoutlines testingproceduresforauditofcompliancetotheserequirements.Someofthe requirementsarerelativelyeasytomeet(itsufficestopurchasecorrectequip-

mentoradheretotechnicalstandards),othersarehardenough(astheyrequire elaborateprocesses).Somenotesonthewaytomeeteachrequirementarefound below.

ControlObjective1ofPTS3.0is“PINsusedintransactionsgovernedby theserequirementsareprocessedusingequipmentandmethodologiesthatensure theyarekeptsecure”.Theobjectiveisbrokendownintoseveralrequirementsas follows:

Requirement1 specifiesthatallcardholder-enteredPINsmustbeprocessedby securecryptographicdevicesandneverappearoutsideoftheminplaintext form.Itfurtherelaboratesonstandardstowhichthesedevicesmustcomply(ISO13491,compliancetowhichisfurtherensuredbycertification ofeitherPCIPTSorFIPS).Anystandarddeploymentofahostorterminalmanagementsystemistohandletherequirement,andcomplianceto specificstandardsishandledbyapropervendorchoice.

Requirement2 coverscardholderPINprocessingincludingonlineandoffline PINvalidation.Therequirementdemandswrittenproceduresandtechnicalmeasureswhichensurethatclerks,merchantsoremployeeswillnever askacardholderfortheirPIN,thatonlinePINtranslationoccurswith approvedkeymanagementmethodsandthattheEPBsareproperlyencipheredintransit.ItfurtherspecifiesthatofflinePINsarevalidatedinaccordancewiththeEMVstandard.Here,too,proceduremanualsarefairly standard,andtheofflineandonlinePINhandlingiscateredforbyadheringtoprovensolutionsandcomplyingwithEMV.

Requirement3 definespermittedEPBformatsforPINblocks.EPBformats0, 1,3and4arepermittedforhost-to-hostcommunicationswhileformat2is usedforreader-to-cardPINtransmission(thelatterconformstotheEMV standard).Therequirementfurtherprohibitstheconversionofstandard EPBformatstonon-standardonesalongtherouteofPINhandling.The requirementtypicallyfollowsfrominteroperabilityneedsascounterparts demandspecificEPBformatstobereceivedfromorsenttothem.

Requirement4 prohibitsstoringEPBsexceptaspartofastore-and-forward transactionandfortheminimumtimenecessary.Furthermore,ifthetransactionislogged,theEPBmustbemasked.Therequirementisusuallysupportedbymajorsoftwarevendorsbutmustbetakenintoaccountduring softwaredesignandimplementationinthecaseofanewsolution.

Requirement5 definesrandomorpseudo-randomgeneratorrequirementsfor keygeneration.IfkeysaregeneratedsolelyusinganHSM,thatiscatered tobydefault.

ControlObjective2ofPTS3.0is“CryptographickeysusedforPINencryption/decryptionandrelatedkeymanagementarecreatedusingprocessesthaten-

surethatitisnotpossibletopredictanykeyordeterminethatcertainkeysare moreprobablethanotherkeys”.Theobjectiveisbrokendownintoseveralrequirementsasfollows:

Requirement6 mandatesthatallprocessesofschememembersmustbesuch thatcompromiseofPIN-handlingprocessescannothappenwithoutcollusionofatleasttwotrustedindividuals.Therequirementisoneofthehardesttocomplywithasittouchesmultiplefacetsoforganizationsatonce. Accordingtotherequirement,clear-textcomponentsmustbesplitbetweenatleasttwodifferentindividuals,general-purposecomputersmust notbeusedtostorethem,provisionsmustbemadetodestroyanyused paperworkthatcontainssensitivematerials,storageofclear-textcomponentsmustbeproperlysecuredandprintingofPINmaterialsmusthappen inclosedenvelopesonly.

Requirement7 prescribestheexistenceofdocumentedproceduresthatare demonstrablyinuseforallkey-generationprocesses.Compliancewith thisrequirementmeansthatallmeasuresmentionedinRequirement6are well-documentedandresponsibleindividualsarefullyawareofdetailed policiesandprocedures.

Requirement8 governstransmissionofprivateandpublickeys.Privatekeys mustbesplitintoseveralpartsandshippedviaseparatechannelsortransmittedinencryptedform,whilepublickeysmustbeshippedinamanner thatensurestheirauthenticityandintegrity.

ControlObjective3ofPTS3.0is“Keysareconveyedortransmittedinasecure manner”.Theobjectiveisbrokendownintoseveralrequirementsasfollows:

Requirement9 definesthetransportationofclear-textcomponentsbetweenlocationsorentities.Thekeysmustbesentinamannerthatpreventsunauthorizedaccessandallowsdetectingitifitoccured.Thatistypically achievedbythemethodandprocedureandtheuseofopaquetamperevidentenvelopes.

Requirement10 mandatesthatanykeyencryptionkeysmustbeatleastas strongasthekeysprotectedbythem.Thatisatechnicalrequirementeasy tomeetdesigningakeymanagementprocess.

Requirement11 mandatesdocumentedanddemonstrablyusedproceduresfor theabove.

ControlObjective4ofPTS3.0is“Key-loadingtoHSMsandPOIPINacceptancedevicesishandledinasecuremanner”.Theobjectiveisbrokendown intoseveralrequirementsasfollows:

Requirement12

demandsthatkeysareloadedintoHSMsandotherdevicesin asecuremannerundertheprinciplesofdualcontrolandsplitknowledge. Therequirementisoneofthekeyreasonsbehindthemeasuresdescribed insection8.3.7.

Requirement13 mandatesthatmechanismsordevicesusedtoloadkeysmust beprotectedfromanytypeofmonitoringthatmayallowunauthorized access.

Requirement14

demandsthatanyaccessandauthenticationmeansusedfor keyloadarestoredunderprincipleofdualcontrol.AtypicalwaytocomplyistodeployHSMswithinanadditionalsecureservercabinetunder twodifferentlockskeystowhicharesplitbetweentwoseparatecustodians.

Requirement15 mandatestheexistenceofmeasurestocheckthatkeysafter theyareloadedareauthenticandhavenotbeencompromised.Thatis typicallyachievedbykeycheckvaluesorotherchecksumswhichmustbe manuallyvalidatedbycustodians.

Requirement16 prescribesdocumentedproceduresdemonstrablyusedaswell asaclearpapertrailfortheabove.Therequirementresultsincopious amountsofpaperworkproducedbyeachkeycustodianoneveryaction theyperformwithkeysorkeycomponents.

ControlObjective5ofPTS3.0is“Keysareusedinamannerthatprevents ordetectstheirunauthorizedusage”.Theobjectiveisbrokendownintoseveral requirementsasfollows:

Requirement17

demandstheuseofuniquesecretkeysforanyidentifiablelink betweenhostcomputers.Compliancewiththerequirementleadstothe introductionoftrustzones(seesection8.3.4).

Requirement18

demandsmeasurestomonitorunauthorizedsubstitutionof keys.Thatisachievedelectronicallybymonitoringsystemsforerrorsand inthephysicalworldbyusingtamper-evidentseals,bagsandenvelopes.

Requirement19

demandsthatkeysareusedforasinglepurposeandarenot sharedbetweenthetestandtheproductionenvironments.Keypurposes areenforcedbyusingsomevariantsorkeyblocks(seesection8.3.3)while theseparationoftestandproductionenvironmentsistypicallyachieved, alongsideacompleteseparationofnetworkanddevices,byonlyensuring defaultLMKsareusedonallHSMsinthetestenvironment.

Requirement20

demandsthatkeysusedintransaction-originatingdevicesare unique,exceptbychance.Thatisachievedbyfollowingexistingpractices ofkeyloadandgeneration.

ControlObjective6ofPTS3.0is“Keysareadministeredinasecuremanner”. Theobjectiveisbrokendownintoseveralrequirementsasfollows:

Requirement21 demandsthatsecretkeysexistinoneofthreemannersonly: eitherinsideasecuredevice,orinencryptedform(withKEKasstrong asthekeyitself,seeRequirement10),orinclear-textformbutseparated intoseveralcomponents.Astandardkeymanagementprocesstakescare oftherequirement:usually,KEKsarestoredinsplit,clear-textformat insidetamper-evidentenvelopesinseparatekeycustodiansafes,whileall theotherkeysonlyexistoutsideofHSMsinencipheredformat.

Requirement22 mandatestheexistenceofkeyreplacementproceduresinthe caseofcompromise.Thenewkeysmustnotbefeasiblyrelatedtothe originalkeys.Thatisbestachievedbyre-generatinganycompromised keyswitharandomnumbergeneratorcomplyingwithrequirement5.

Requirement23 prescribesthatanykeysgeneratedwithareversiblekeycalculationmethodssuchaskeyvariantsmustonlybeusedintheoriginal HSMsandonlyatthesamelevelofkeyhierarchy(e.g.,aKEKvariant mustnotbeusedtoencryptdataorasamasterkey).Seealsosection8.3.3 fordetails.

Requirement24 prescribesproperdestructionofthekeysthatarenolongerin use.

Requirement25 mandateslimitaccesstosecurekeysonlimitedneed-to-know basisandinaprotectedmannersothatnootherpersoncouldobtainorobservethecomponent.Thatisdonebystoringallmaterialsinsafesaccessiblebyafewkeycustodiansandbyinstructingcustodiansaccordingly.

Requirement26 prescribeskeepingdetailedlogsforanykeymovementinor outofstorageandintosecuredevices.Thatagaincontributestopaperwork thekeycustodianshavetocarryandmaintain.

Requirement27

coversthebackupsofkeysandkeycomponents.Therequirementisthat,ifpossible,nobackupsarekeptbutiftheyare,theymustbe adequatelysecuredandrestrictedtotheabsolutenecessaryminimum.

Requirement28 prescribestheexistenceofdocumentedproceduresdemonstrablyused.

ControlObjective7ofPTS3.0is“EquipmentusedtoprocessPINsandkeysis managedinasecuremanner”.Theobjectiveisbrokendownintoseveralrequirementsasfollows:

Requirement29 prescribesmakingsurethatanydeviceputintoproductionhas notbeentamperedwith.Thatisachievedbyinstatingstrictvalidationproceduresoftheincomingequipmentshipmentsandbymaintainingaclear papertrailofsuchprocedures.

Requirement30 demandsphysicalandlogicalprotectionfordevices.That meansmakingsurephysicalaccesstodevicesisrestrictedandwelldocumentedanddevicesareroutinelypatchedforknownvulnerabilities.

Requirement31 governsproceduresfordestructionofthedevicesthatareno longerinuseandthedestructionofkeymaterialsinthecaseoftakinga devicetorepairs.

Requirement32 demandsthatanydeviceusedtogenerateandencryptkeys isrestrictedinuseandaccess.Thatisachievedbydualphysicalcontrol asmentionedinRequirement14andbymakingsurethedeviceenters keygenerationmodeunderdualaccess(standardfeatureofanycompliant HSMvendor).

Requirement33 prescribestheexistenceofdocumentedproceduresdemonstrablyused.

8.3.7KeyCustodiansandKeyCeremony

Asmentioned,oneofthekeyprinciplesofproperaccessmanagementtokeys andkeycomponentsisdual-ormulti-partycontrol.Inatypicalset-upaprocessinginstitutionnominatesatleastthree keycustodians oremployeestrainedand qualifiedforthejobbutnotbelongingtothesamedepartmentorreportingto thesamedirectmanager.Itiscustomarytoalsonominatebackupkeycustodianswhoshareaccesstocryptographicmaterialswiththecorrespondingprimary custodians.

Eachcustodianisallocatedasafeboxinsidewhichthecustodian’scryptographicmaterialisstored.Usuallyeachkeycomponent,acryptographicorphysicalkey,asmartcardorothermediaisenclosedinadditioninatamper-evident envelopetoensureanadditionallevelofthesensitivedataprotection.

KeygenerationprocessesandaccesstosuchhardwareasHSMsarearranged insuchamannerthatthepresenceofallthethreecustodiansismandatory.The processofgenerationofclear-textkeycomponents,keyrecombinationandimportiscalled keyceremony.Duringtheprocesssensitivestepsareperformed bykeycustodiansinseclusiontoavoidthepossibilityofkeyorkeycomponent compromise.

8.3.7.1SampleProcedure

Toillustratetheaforementionedrequirementsandprinciples,considerthefollowingsamplekeymanagementprocedure.Itisbynomeanscompletebut shouldprovideageneralideaofhowacompliantprocessingorganizationshould defineitsguidelines.

Assumethatapureacquiringplayersupportscard-presenttransactionswith onlinePINand,therefore,requiresPINtranslation.HSMsrequiredtosupport thepredictedvolumearesupposedtobepurchasedfromacertifiedvendor;the packagingissupposedtobeinspecteduponreceiptfortamperingandthestorage andhandlingofHSMsfurtherdocumenteduntilthemomenttheyaresecurely deployedinaserverfarm.

ToensureaproperaccesscontroltheHSMsareplacedinaseparateclosed cagewithduallocksonitsfrontandback(forexample,byusingabuilt-inlock andapadlock).ThecustodiansgatheratanHSM,inspectitforsignsoftamperingandinitializethemasterkeys.Thekeysarestoredonatleasttwosmartcards assignedtodifferentcustodians.EachcustodianassignsanadditionalPINcode tothesmartcardinseclusiontoavoidotherspeeking.

ThecustodiansaddanentrytotheHSMaccesslog,lockuptheHSM,seal theirsmartcardsandphysicalkeysinseparatetamper-evidentenvelopeskept withthematalltimesuntiltheirdepositinasafebox.

Eachcustodianisgivenasafeboxtowhichonlythisparticularprimaryor backupcustodianhasaccess.Thecustodianmaintainsaninventoryofthesafe boxmarkingnewanddestroyeditemsaswellasanaccesslogcontainingthe detailsoneachpieceofcryptographicmaterialtakenoutorplacedbackintothe safebox.

WhenitistimetogenerateaZMKthecustodiansgatheragainatafacility withHSMaccess.Custodians1and3havephysicalkeysallowingthemtoactuallytouchthedevicewhilecustodians1and2havesmart-cardsallowingkey generation.InthecaseofsuchdistributionoftheaccessartefactsnotwocustodianscancolludetogainunauthorizedaccesstotheHSMorotherwisecompromise sensitivematerials.

ThecustodiansinspecttheHSMexterior,thenenableaccesstoitand,ifrelevant,putitinnecessarymodetogeneratetheZMKs.Thecustodiansapproach theHSMconsoleeachinturnandgenerateakeycomponentoftheZMK.Each generatedcomponentistobewrittendownbyitscustodianonadedicatedform andkeptoutsideofotherobservers’eyes.Thecustodiansalsomakesurethatno personapproachingtheHSMafterthepartofthatparticularcustodianiscompletedisabletoseetheclear-textkeycomponent(forexample,byclearingthe screenoncetheclear-textcomponentiswrittendown).

Thenthecustodiansrepeattheceremony,thistimeenteringtheclear-text componentsintotheHSMtoformaworkingZMK.Oneofthecustodianswrites downthevalueofZMKunderLMKonaformforfutureuse.Thenthecustodians returnHSMtooperationalmode,ifnecessary,andlockitupagain.Theysealthe clear-textcomponentsintamper-evidentenvelopes.

Next,eachcustodianhastosendtherespectivekeycomponenttotheother party’scounterpart.Thebestpracticetodoitisdoingthatondifferentdatesand usingdifferentdeliverymethodsdeliverysuchasmailandcourierservices.Each custodianmustknowexactlytowhomthecomponentissentandcommunicate

thetrackingnumbersand/orpackageserialnumberstothatperson.Theother party’scustodiansmustconfirmthereceiptofmaterials,inspectthemfortamperingandplacethemintosecurestorage.Incaseanenvelopebearssomesigns oftampering,itscontentsdonotmatchthemanifestortheserialnumberofthe packageiswrong,theentirekeyisconsideredcompromisedandtheprocessis restarted.

Besideshardcashand”pure”cardpaymentsdescribedinthebook,severalother paymentmethodshaveemergedovertheyears.Someofthemfunctionasacompletealternativetopaymentcardswhileothersmimicpaymentcardtechnology orcomplementit.Certainly,cryptographiccurrenciesstandoutasanentirely differentmethodoftechnologypracticallydenominatedinacurrencyofitsown. Thesemethodscanbelargelydividedintothefollowinggroups: Electronicwallets(stagedorpass-through)

Letustakeabrieflookintothesegroupsinsomemoredetails.

9.1ElectronicWallets

Consideranold-schoolphysicalwallet.Itistoppedupwithcashandcanalso containpaymentcards.Aconsumergoestoastore,takesoutsomecashfrom thewalletandpaysforgoodsandservices.Oncethecashinthewalletrunsout, ithastobetoppedupagain.Theconsumercanalsopickacardoutofseveral onespresentinthewalletanduseittomakeapayment.

Ingeneral, electronic (or digital) wallets mimicphysicalwallets.Theycan bedividedintotwosubgroups:stagedandpass-throughones.

A stagedwallet isadigitalwalletusedinstages.Thatis,itisananalogyof cashbeingplacedintoandtakenoutofawallet:astagedwalletisusedinstages, hencethename.Thefirststageistop-upduringwhichmoneyisplacedintothe walleteitherbyasinglepayment-cardtransactionorviaabanktransferorviaa cashdepositinakioskorasupportingstoreor,finally,viaapeer-to-peertransfer fromanotherholderofthesamewallettype.

Stagedwalletsareprimarilyusedforcard-not-presentpurchases.However, brick-and-mortarshopsbecomeincreasinglymoreableandwillingtoaccept paymentsfromsuchwallets.

Fromthecardschemes’perspectiveastagedwallethassomeregulatoryand fiscaldrawbacks.

Fromaregulatorypointofviewitisnolongerpossibletotrackeachindividualtransactionoriginatedviaascheme-brandedcard.Money,oncetoppedup inastagedwallet,canbeusedforanypurposeallowedbythewalletprovider, includingillegalfundtransfersandlaundering.

Fiscally,eachtransactionthatbypassescardschemenetworksmeanslower feesforthecard-schemeandlessinterchangeforparticipatingbanks.

Assuch,cardschemesareimposingadditionalfeesandrequireextradataon stagedwallettransactions.

TheexamplesofstagedwalletsincludeWebMoneyinRussia,Osaifu-Keitai inJapanorsuchglobalprovidersasSkrillandPayPal.

A pass-through walletisadigitalwallethavingoneormoreunderlyingpaymentcardsthatcanbeusedtoperformaparticulartransaction.Eachtransaction withapass-throughwalletistranslatedtoatransactionwithoneofthecardstied toit.

Pass-throughwalletswerebroughtovertothecard-presentspacewiththe introductionofApplePay.InthecaseofApplePay,oneormorepaymentcards aretiedtoaperson’saccountwithApple.Byleveragingcardtokenizationa consumerhavinganiPhoneusingNFCtechnologycantransmitpaymentdetails toacontactlessterminalinastorewithouttheneedforthestoreownertoupdate terminalhardwareorsoftware.

Otherwallets,suchasAliPayorWeChatPay,relyonaQRcodescanfora transferoffundsbetweenconsumer’sandmerchant’swallets.

Theexamplesofpass-throughwalletsincludeAmazonPayments,PayPal, ApplePay,SamsungPay,AliPayavailableglobally,andlocalproviderssuchas BKMExpressinTurkey.

Cardschemeshavealsomadesomeforaysintothefieldofpass-throughwalletsintroducingVisaCheckoutandMasterPass,tonameafew.

Thetwomodesofoperationofadigitalwalletarenotmutuallyexclusive.For instance,PayPalcanbetoppedupasastagedwalletandusedasapass-through dependingonauserpreference.

9.2Cash-basedMethods

Thepaymentmethodisusedforonlinepaymentsinmarketswithlowpenetration ofpaymentcards.

Aconsumerperformsapurchaseinane-commercestorechoosingcash voucherasthepaymentmethod.Theconsumergetsaprintabledocumentwith auniqueidentifieronit.Thentheconsumertakesthedocumenttoaparticipatingservicepointoranautomatedkioskanddepositscashtothefullspecified amount.Oncethevoucherispaidincash,theonlinestoreshipsthegoodsor providestheservices.

Multipleexamplesofthemethodcanbefoundindevelopingmarkets.To nameafew,EfectyinColombia,ESAPAYinMalaysiaandBrunei,andFawry inEgyptarecash-basedonlinepaymentmethods.

9.3TelcoBilling

Inmanymarketswithlowbankingaccessandpayment-cardpenetration,consumerswidelyusetelecomserviceprovidersaspost-paidorpre-paidcustomers. Consequently,manyonlineandbrick-and-mortarstoresallowconsumersto payforgoodsorservicesfromtheircellularphonebalanceorbyincludingthe paymentintheirnexttelecombill.

Themethodiswidelyusedindevelopingmarketswheremobileaccesspenetrationisfargreaterthanthepercentageofbankedpopulation;examplesinclude FloozinTogoandBeninandFNBCellPayPointinSouthAfrica.

9.4BankTransfers

InmaturemarketswithubiquitousaccesstobankingservicessuchastheUnited States,UnitedKingdomorEuropeanUnion,therearepaymentmethodsfacilitatingfundtransferbetweenaconsumer’sandamerchant’sbankaccounts.

Certainly,aconsumercouldapproachalocalbranchoftheirbank,instructa clerktowiremoneytothemerchantand,uponconfirmation,havethemerchant shipthegoods.Themethod,however,isnotsuitableforonlinepurchasesandso aplethoraofbanktransferpaymentmethodshaveemergedbothsimplifyingthe authorizationofthefundtransferonlineandspeedingupthetransferoffunds itself.

Forexample,suchmethodsincludeACHintheUnitedStates,Faster paymentsintheUK,SofortinGermany,iDEALinBelgium/Netherlands/ Luxembourgearea,eDankortinDenmarkaswellasSEPADirectDebitelsewhere(oreverywhere)intheEuropeanUnion,eNETSinSingaporeandsoon.

9.5Invoices

Incertainmarketstherearepayment-servicesprovidersallowingconsumersto paybyinvoice.

Whensuchmethodisused,themerchantusuallyreceivesthefullpaymentamountwhiletheconsumerisinvoicedperiodicallyoveraspanofseveral months.Themethodlaysofftheilliquidityrisksfromthemerchanttotheserviceproviderwhile,ontheotherhand,providingfinancingtotheconsumerin theformofinstallmentpaymentsoverwhatoriginallyisalumpsumpayment.

9.6DigitalCurrencies

Digitalcurrencies,especiallythepioneeringBitcoin,areanentirelynewbreed ofpaymentmethodunrelatedtoanyexistingcurrencyortechnology.

Inthecaseofablock-chain-baseddigitalcurrencythereisnosingleauthority thatissuesorcontrolsthepaymentinstrumentasthatroleisdistributedbetween multiplenodesinalow-trustnetworkof“coinminers”.

Theconversionbetweenadigitalandatraditionalcurrencyisnotapartof digitalcurrencymechanisms(unlikeelectronicwallets)andisinsteadperformed similarlytoforeigncurrencyexchangesbyadigitalcurrencybroker.

Asdigitalcurrenciesarebuiltinaninherentlyanonymousanduntraceable manner,acceptingoracquiringpaymentswiththeinstrumentinvolvesasignificantlegalriskbecauseitisacomfortablechannelforillegalactivitiesandmoney laundering.Furthermore,thelegalframeworkinmostcountriesisnotprepared forthattypeoffinancialinstrument.

Theaforementionedfactorscontributetothevolatilityofdigitalcurrencies. However,despitethatconsumersareincreasinglywillingtousedigitalcurrencies andmerchantsconverselyexpecttobeabletoacceptthem.

ALGORITHMS ANDENCODINGS V

Chapter10 ValidationAlgorithms

CONTENTS

10.1LuhnAlgorithm 211 10.2LongitudinalRedundancyCheck(LRC) ............................ 212 10.3KeyCheckValue(KCV) ........................................... 213

10.1LuhnAlgorithm

TheLuhnalgorithmisspecifiedbytheISO/IEC7812-1standard.Validationof anaccountnumberisperformedaccordingtothefollowingsteps:

1.Truncatethecheckdigitfromthenumberthatisbeingvalidated. 2.Movingrighttoleft,doublealldigitsonoddpositions(i.e.,therightmost oneandeveryotherdigitleftwardsfromit). 3.Iftheproductofdoublingadigitisgreaterthan9,replacetheresulting numberwiththesumofitsdigits. 4.Sumuptheresultandaddthecheckdigittoit. 5.Theresult,modulo10,shouldbe0. Considertheexampleofaccountnumber491023693576shownin figure 10.1 Thesumofalldigitsis8 + 9 + 2 + 0 + 4 + 3 + 3 + 9 + 6 + 5 + 5 + 6 = 60 whichdividesby10.Hence,6isavalidcheckdigit.

Figure10.1:ExampleofLuhnalgorithm

Tocalculatethecheckdigit,followsteps1to4ofthealgorithmabove,assumingthecheckdigitof0.Ifthetotalamountisalreadydivisibleby10then0 isthecheckdigit;exit.Otherwise,replacethecheckdigitwith10lessthesum modulo10.

Asitisquiteeasytosee,amistakeinanysingledigitoftheaccountnumber causestheLuhnchecksumtobecomeinvalid.Thechecksumalsodetectsalmost anytranspositionoftwoadjacentdigits,exceptfor09becoming90orviceversa.

ThatmakestheLuhnchecksumaneasyandpracticalmethodtovalidatePAN numbersduringmailortelephoneordersaswellasinelectroniccommercepurchaseswhenthecardispunchedinorwrittendownbyahumanandistherefore mostpronetothesetypesofmistakes.

10.2LongitudinalRedundancyCheck(LRC)

TheLongitudinalRedundancyCheckorLRCisusedasthetrailingvalueofthe datastoredonthemagneticstripe.Itisatypeofredundancycheckalgorithm easytoimplementinbinaryhardwareandparticularlygoodatdetectingnoiserelatederrors.

TheLRCisbestdefinedasthe8-bittwo-complementvalueofthesumofall bytesmodulo28,meaningthatthesumofallthevaluesandtheLRCyields0.

TocalculatetheLRCvalueXORallbytesofthebytearrayinquestion,then calculatethetwo-complementvaluebyinvertingtheresult(XOR-ingwith0xFF) addingoneandthentakingmodulo28 again(whichcanbedonebyAND-ingthe valuewith0xFF).

Toillustrate,considertheexampleof FA1358A0C5.

XOR-ing0xFA,0x13,0x58,0xA0and0xC5yieldsthevalueof0x8C.To calculateitstwo-complementweXORitwith0xFFandobtain0x73astheresult. Thenweadd1toget0x74whichisthedesiredLRCvalue.

TovalidatethecalculationaddthesumofallthevaluestothecalculatedLC value.Theresultis0x100whichonceANDedwith0xFFyields0.

10.3KeyCheckValue(KCV)

TheKeyCheckValueorKCVisusedtoconfirmthekeysvalidityandisutilized forthevalidationofencryptionkeysinthepaymentsindustry.

AKCVistypicallya3-byte(6digits)controlvaluetransmittedalongside anencipheredkeyorwithclear-textcomponents.Itisobtainedbyencryptingan inputblockofzeroeswiththeappropriatealgorithm(seesection12.2andsection 12.3).Oftheoutcomeonlythefirstbytesarekeptandtherestarediscarded.

ItispossibletousealongerorshortervaluefortheKCVutilizinglessor morebytesbutthe3-bytevalueisthedefactostandardintheindustry.

Chapter11 CodeTables

CONTENTS

11.1ANSI/ISOALPHADataFormat 215 11.2ANSI/ISOBCDDataFormat ....................................... 215 11.3ASCIICharacterEncodingTable ................................... 216 11.4EBCDICCharacterEncodingTable ................................ 217 11.5Base64Encoding .................................................. 218 11.6BER-TLVEncoding ............................................... 220 11.6.1TagorTypeIdentifier ...................................... 220 11.6.2Length ................................................... . 221

11.1ANSI/ISOALPHADataFormat

Table11.1 containstheANSI/ISOALPHAdataformatusedtoencodeTrack1 values.Thedataisstoredin7-bitvectorswiththeleastsignificantbitbeingthe parity(thus,thecharacterof‘’isstoredas0000001).

11.2ANSI/ISOBCDDataFormat

Table11.2 containsANSI/ISOBCDdataformatusedtoencodeTrack2and Track3values.Thedataisstoredin5-bitvectorswiththeleastsignificantbit beingtheparity(thus,thedigit0isstoredas00001).

Table11.1:ANSI/ISOALPHAdataformat

Table11.2:ANSI/ISOBCDdataformat

TelegraphAlphabetwhich,asitspredecessor,hadshiftcodeschangingthemeaningofthesymbolcodes,modifyingregistersoralternatingbetweendigitsand letters.

In1963,theASCIItablewaspublished.Besideseliminatingtheneedforshift controlcharacters,thetablehadseveralotherusefulfeatures.Thekeyproperties oftheASCIIencodingtablearelistedbelow:

ASCIIcontrolcharacters(e.g.,“linefeed”or“newline”)havecodesin therangeof0x00to0x1F(0to31).Also,0x7Fisacontrolcharacter.

ASCIIdigitsarecodedstartingfrom0x30(48)throughto0x39(57).In otherwords,andthatcomesinhandywhenanalyzingISOmessages,to formanASCIIcodeforadecimaldigititissufficienttoadd0x30toit. Forexample,sequence“3790”isencodedinASCIIas 33373930

Spaceisencodedas0x20(32).

Uppercaselettersareencodedinpositions0x41through0x5Ainalphabeticalorderandlowercaselettersareencodedinpositions0x61to0x7A. Inotherwords,turningonandoff6thbit(adding/subtracting0x20)providesaneasymethodtoconvertASCII-encodedstringsbetweenupper andlowercase.

InsubsequentrevisionstheASCIIstandardwasexpandedto8bitsandcodes in0x80-0xFFrangewereallocatedtoadditionalnationalcharacters.Thesecode pageshavelargelybeenreplacedbybackward-compatibleUTF-8encodingin wideuse.

InthepaymentsindustrymostapplicationsandcertainlyallonlineauthorizationprotocolsonlyusethelowerrangeofASCIItablewithnationalencodings sometimesusedinclearingfiles.

A7-bitASCIItableisveryeasytofindontheInternetandis,therefore,not broughthere.

11.4EBCDICCharacterEncodingTable

EBCDICstandsforExtendedBinaryCodedDecimalInterchangeCode.Itisa proprietary8-bitcharacterencodingdevelopedandfirstusedbyIBMonmainframesandminicomputers.ItwasdevisedandannouncedbyIBMin1963,the sameyearASCIIencodingcameintobeing.

AlthoughIBMactivelyparticipatedinthedevelopmentofthenew7-bit character-encodingstandard,thefullmigrationofexistingsoftwareandperipheraldevicestothenewstandardwasconsiderednotfeasible,soinsteadIBM hadtomaintainbackwardcompatibilityand,therefore,EBCDICwasanincrementalextensionofearlierBinaryCodedDecimalInterchangeCode(BCDIC) encodingsusedbyperipheraldevicesthatprocessedorpunchedpunchcards.

DuetothevastpopularityofIBMmainframecomputersoperatingsincethe early1960sandtothisdayinfinancialinstitutionsacrosstheglobetheencoding lingered2

EBCDIChasseveralnotableproperties:

WhileASCIIuses7bitstoencodeLatincharacters,EBCDICusesfull 8-bitcodes.

TherearemultipleEBCDICcodepageswhicharenotfullycompatible.

Control(non-printable)charactersareencodedintherange0x00to0x3F. 0xFFisalsoacontrolcharacter.

TherearethreecharactersforspacesinEBCDIC:0x40(decimal64, space),0x41(decimal65,requiredspaceorno-breakspace)and0xE1 (decimal225,numericspace).The0x40charactercorrespondstoASCII code0x20(decimal32,space).

Decimaldigitsareassignedcodesfrom0xF0(240)to0xF9(249).Therefore,toencodeadigitinEBCDICformatitissufficienttoadd0xF0toit. Forexample,sequence3790isencodedinEBCDICas F3F7F9F0

Latinuppercaselettersareencodedinranges0xC1to0xC9(decimal193 to201,lettersAtoI),0xD1to0xD9(decimal209to217,lettersJtoR) and0xE2to0xE9(decimal226to233,lettersStoZ).Lowercaseletters occupyparallelcoderanges0x80to0x89,0x90to0x99and0xA1to 0xA9.

3.Each6-bitvalueismappedtoacharacteraccordingtotheencodingtable, exceptfortrailingpaddingzerovaluesreplacedwithaspecialpadding character,=.

Theencodingtableiseasytolocateinthepublicdomain.

Toillustratethecalculationletusconsiderthefollowingbinarysequenceof 5octets: DEADBEEF00.Toencodethesequenceitshouldbepaddedto6 octetsforthetotallengthtobedivisiblebythree.Inbinaryform,theresulting stringisrepresentedin figure11.1

Figure11.1:Base64paddedinputstring

Thetotalbitlengthoftheresultingsequenceis48bitshence,itwillbeencodedwith8characters,onepereach6-bitword,asshownin figure11.2

Figure11.2:Base64encodedstring

Theresultingsequenceisthereforeencodedas 3q2+7wA=.Notethatthesame binaryvalueof0isencodeddifferentlywhenitispartoftheoriginalbinarydata (inwhichcase,0ismappedtoA)andwhenitisapaddingbyte(andismapped to=).

11.6BER-TLVEncoding

BER-TLVstandsforBasicEncodingRules—TagLengthValueandrefersto BERencodingofASN.1.

ASN.1standsforAbstractSyntaxNotationOneandisastandarddescribinga languagefortheabstractdescriptionofarbitrarydatastructuresaswellasseveral setsofrulesthatallowencodingandtransmissionofthesestructures.

BERorBasicEncodingRulesisoneofsuchrulesetsanditisusedinthe paymentindustryaspartofEMVchipandcontactlesstechnology.ItissometimesreferredtoasBER-TLVorTLV(tag/length/value)sinceeachdataelement isencodedastypeidentifierfollowedbyelementlength,followedbydataand optionallyconcludedbyanend-of-contentmarker(thelatterisnotusedinpaymentsandisthereforenotcoveredhere).

11.6.1TagorTypeIdentifier

Asmentionedabove,aBER-encodeddatastructurealwaysstartswiththetype identifieror“tag”occupyingatleast1byteandpotentiallyunlimitedinlength.In practice,tagsthatareusedinEMVapplicationsareeither1or2bytesinlength. Thebitpatternofa1-bytetag,asprescribedbytheBER-TLVstandard,is shownin figure11.3.

Figure11.3:BER-TLV1-bytetag

Incasethetagnumbercannotfitinto5bits,all5juniorbitsofthefirstbyte shouldbesetto1andtheformatoftheresulting2-bytetagisasshownin figure 11.4.

Figure11.4:BER-TLV2-bytetag

HeretheMorthemostseniorbitofthesecondbyteissetto1ifanotheroctet withtagnumberfollows(i.e.,totallengthofthetagisatleast3bytes).Ifany additionalbytesarerequiredforthetagnumber,theirformatisidenticaltothat ofbyte2.Asmentionedabove,inEMVapplicationsnotagidoccupiesmore thantwobytes.

Thetagclassvaluesaredefinedin table11.3.

TheEMVstandardonlyutilizesthevaluesof1and2foritstagmeaningthat allEMVstandardtagsbeginwithbitsequence01or10.

TheP/Cbitindicateswhethertheelementfollowingthetagisprimitive(i.e. containstheactualvalue)orconstructed(iscomposedofmultipletag-lengthvaluesub-elements).Thevalueforconstructedonesis1.TheEMVstandard containsbothprimitiveandconstructedtags.

Theremainderofthetagistheactualtagnumber.Forasingle-bytetagitcan rangefrom0to30.Ifthevalueofthesebitsissettoallones(i.e.,tagnumber 31),thenumberiscontinuedinthesecondbyte.

11.6.2Length

Thelengthcanbeencodedineitherashortoralongform.

Intheshortformthelengthinbytesisencodedasasingle-bytevaluewith mostseniorbytesetto0.Thatallowsencodingvaluesofupto127byteslength. Forexample,avaluewithlengthof75bytesisrepresentedasthebitstringof 01001011

Inthelongformtheleftmostbitofthefirstbyteofthelengthvalueisset to1whiletheother7bitsrepresent“lengthoflength”ornumberofbytesthat followandcontainthelengthoftheactualbinaryvalue.TheEMVstandardonly useslengthsofupto255bytesand,consequently,onlyrequiresatotalof2bytes forencodinglengthsinthelongform.Forexample,thevalueof140(binary 10001100)isencodedasshownin figure11.5.

Here,bit8ofbyte1indicatesthelongformofthelengthvalueandbits7to 1indicatethatonly1byteistofollow.Byte2containsthefull-lengthvaluein bytes.Asmentionedabove,theEMVstandarddoesnotuselongerformsofthe lengthvalue.

Table11.3:Tagclassvalues

Figure11.5:Sampledouble-bytelengthvalue

Chapter12 Cryptography101

CONTENTS

12.1Introduction 223 12.2DESand3-DESEncryption ........................................ 225 12.3AESAlgorithm ................................................... . 226 12.4MessageAuthenticationCode ...................................... 226 12.5AsymmetricEncryption ............................................ 227

12.1Introduction

Thepurposeofthechapteristoprovidebasiccryptographictermsandtheir definitionstotheextentrelevantforunderstandingofpayment-processingtechnology.

Paymentprocessingimpliespassingaroundsensitivedatabetweenpartiesor datawhichneedstobeprotected.Sincethefullcontrolofallphysicalaccessto hosts,devices,networkelementsandevencablesparticipatinginpaymentprocessingisnotfeasible,theindustryreliesoncryptographicmeansofmessages protectionduringtheirexchangebetweenparties.

Araworundisguisedmessageiscalled plaintext or cleartext.Tohideits substanceisto encrypt or encipher it,obtaining ciphertext astheresult.The reverseprocessiscalled decryption or deciphering

Cryptographyhasthefollowingmajorfunctions:

Confidentiality—ensuringthatthemessageisonlyseenbyitssenderand recipientandthatathirdpartythatmightbeeavesdroppingonthe

communicationchannelisunabletodiscernitscontents.Theabilityis widelyusedtokeepchannelsbetweenpaymentpartiessecured.

Authentication—allowingthereceiverofthemessagetoconfirmitsoriginso thatathirdpartywillnotbeabletomasqueradeasasender.Forinstance, authenticationisusedtoconfirmthatthechiponthecardfromwhichthe transactionoriginatedisgenuineasissuedbythebank.

Integrity—allowingthereceivertoverifythatthemessagehasnotbeentamperedwithintransit.Forinstance,duringafull-gradeEMVchiptransactioncryptographicmethodsensurethatitsamounthasnotbeenmodified.

Nonrepudiation—notallowingthesendertodenythatthemessagewasindeed sentbyit.

Atypicalcryptographicalgorithmacceptstwoparameters:thedata(cleartext tobeencipheredorciphertexttobedeciphered)andthe key.Thekeycanbekept secretwhilethealgorithmmaybeexposedtoindependentscrutiny.

Cryptographicalgorithmscanbeclassifiedinto streamciphers and blockciphers.Astreamcipheroperatesonabyteorabitofcleartextatatimewhilea blockcipheroperatesonafixed-sizedatavector(typically8bytes/64bitor16 bytes/128bit).

Algorithmscanbefurtherclassifiedbasedontheiruseofkeysforencryption anddecryption.Ifthesamekeyisusedtobothencryptanddecryptthemessage, thealgorithmiscalled symmetric (seealsosection12.2,describingtheDESalgorithmwhichisasymmetricblockcipher).Ifdifferentkeypairsareusedfor encryptionanddecryption,thealgorithmis asymmetric.Here,inthecaseofdata encryption,theencryptionkeyisusuallycalledthepublickeyandthedecryption keyisusuallycalledtheprivatekey.

Besidesalgorithmswhichencryptanddecryptmessages,moderncryptographicsystemsalsouse one-wayhashfunctions.Aone-wayhashfunctionconvertsavariable-lengthinput(amessage)intoafixed-lengthoutput(themessage digest).Suchafunctiondiffersfromanalgorithmbecauseitisunfeasibletorestoretheoriginalmessagebasedonitsdigest.One-wayhashfunctionsserveras atoolforthegenerationofMAC(messageauthenticationcode)whereasecret keyisaddedtothemessagebeforeaone-wayhashfunctionisappliedtoit.

Public/privatealgorithmsarewidelyusedtobothencryptandsignthedata sent.Togenerateadigitalsignaturethesendercanproduceaone-wayhashof themessage(appendingtimestamptoittoavoidreplayattacks)andencryptthe messagedigestwiththeirprivatekeysendingboththemessageandtheobtained signaturetotheotherparty.Thenthereceivergeneratesthesameone-wayhash, decryptsthesignaturewiththesender’spublickeyandcomparestheresulttothe receivedvalue.Ifthehashesmatch,thesignatureisvalid.

Thereareseveralmethodstoapplyablockciphertoadataarraywhoselength isbiggerthanthecipher’sinputblocksize.Firstandforemost,thedataispadded

toalengthdivisiblebyblockcipherinputblocklength.Twomostcommonmethodstoencryptthepaddeddataare ECB(electroniccodebook) and CBC(cipher blockchaining).InthecaseoftheECBmodeeachblockisencryptedindependently(increasingvulnerabilityoftheoverallsolutiontosomeattacks,asidenticalinputswouldyieldidenticaloutputs).InthecaseoftheCBCmodethedata isencryptedsequentiallywithencryptedvalueofoneblockbeingXOR-edwith plaintextofthesubsequentblockpriortoitsencryption.Thefirstblockinthe chainisXOR-edwithaspecialvaluecalledwhichneedstobecommunicatedto therecipientoftheciphertextsothattheycoulddecipherthemessage.

12.2DESand3-DESEncryption

TheDES(DataEncryptionStandard)algorithmisasymmetricblockcipherdevelopedintheearly1980sbyIBMresearchersjointlywiththeNSAanddefined asastandardalgorithmforsymmetricdataencryptionforUSgovernmentagencies(FederalInformationProcessingStandardorFIPS).

Thealgorithmcontainsseveralkeystepsdesignedinamannerthatbothpreventsmostcryptographicattacksandissuitablefordevelopmentofspecialized hardwarethatcanperformnecessarycalculationsfasterthanasoftwarecounterpart.

TheDESalgorithmisablockcipherthatoperateson64-bitblocksenciphering8-byteplaintextinto8-byteciphertext.Overthecourseofthealgorithmthe blockispermutedandthenbrokeninto32-bithalvesandcombinedwiththe keyrepeatedlyfor16rounds.Attheend,thehalvesarerecombinedandafinal permutationisperformed.

ThekeylengthoftheoriginalDESalgorithmwas8bytesor64bits.One bitofeverybytewasunusedbythealgorithmandwasthusutilizedasaparity checkvalue.Ascomputationalpowerofgenerallyavailablehardwaregrew,the algorithmhadtobeaugmentedaccordinglyandthus3-DESorT-DESencryption algorithmwasdesigned.

Asitsnameimplies,thealgorithmutilizesthreekeysK1,K2 andK3 applied toeachdatablockinsuccessionencryptingwithK1 andK3 anddecryptingwith K2: C = EK1 (DK2 (EK3 (M)),where C istheciphertextand M isthemessage. Similarly,thereversetransformationisdonebydecryptingwithK1 andK3 and encryptingwithK2: M = DK1 (EK2 (DK3 (C))

Asaninputthealgorithmcanreceiveone,twoorthreekeysanddepending onthatthevariantofthealgorithmissometimesdenotedas1TDES,2TDESor 3TDEScorrespondingly.Withonekey,i.e.,whenK1 = K2 = K3,thealgorithm isreducedtothestandardDES,andwithonlytwokeysK1isassumedtobe equaltoK3.Thesekeysareusuallytransmittedandrecordedasaconcatenated

arrayof8,16or24bytescorrespondingtoeffectivekeysizesof56,112and168 bits.

12.3AESAlgorithm

Bytheendofthe20thcentury,therehadbeenseveralconcernswithregardsto DESanditsTDESvariation.Progressinhardwaremadepossiblespecializeddevicesthatcanbrute-forceasingleDESencryptioninaveryshorttimeframe.The algorithmaswellasitstripledcounterpartweredesignedforhardwareimplementationandranrelativelyslowwhenimplementedinsoftware.Furthermore, theblocksizeof64bitswasconsideredtoosmall.

ItwasduetotheissuesthatanAdvancedEncryptionStandard(AES)selectionprocesswasinitiatedbyNISTintheUnitedStates.Eventually,analgorithm calledRijndaelwasacceptedasthenewofficialstandardforsymmetricdataencryption.

Thealgorithmworksonblocksof128bitswithkeysof128,192or256bits inlength.Thealgorithmrepresentstheinput16bytesasa4 × 4column-major matrixandperforms10,12or14roundsofencryptionforkeysof128,192or 256bits,correspondingly.Aroundkeyisderivedfromtheprovidedencryption keypereachroundofencryption.Thenthealgorithmperformsthefollowing steps:

TheroundkeyisXORedwiththeinputmatrix.

For9,11or13roundsmatrixbytesaresubstitutedaccordingtoasubstationtable.Thenthealgorithmshiftsrowsofthetable,effectivelymixing bytesacrosscolumnsandthenmultiplieseachcolumnbyacoefficient matrixobtainingalinearcombinationoftheinputbytes.Theresultis XORedwiththeroundkeyfortheappropriateround.

Inthefinal-roundbytesaresubstitutedandrowsareshifted,andthenthe resultisXORedwiththefinalroundkey.

Thealgorithmisconsideredverysecure.TheEMVstandardincludesthedescriptiononitsuseincryptogramgenerationwhilethePINTransactionSecurity 3.0standardmandatestransitiontoitforEPBencryption.

12.4MessageAuthenticationCode

AMessageAuthenticationCodeorMACisashort(relativetothemessagesize) valueusedtoauthenticateamessage.Itisdifferentfromachecksumorahash valueasitistypicallycalculatedusingasecretkey.

InpaymentstheMACtypicallyinuseisavariationcalledCBC-MAC, whereasablockcipheralgorithmisusedinCBCmodeoverthemessagewith aninitializationvectorof0.Thenonlytheoutputofthelastencipheringround issent.

Toillustrate,considertheTDESalgorithmandamessagethatisof24-byte lengthafterpadding.CBCencryptionwithinitializationvectorofallzerosmeans thatfirst8bytesofthemessagearetobeencryptedasiswiththeTDESkey resultinginvalueofH1.ThenH1isXOR-edwiththesecond8bytesofthe messagedata.TheresultisencryptedtoobtainH2.H2is,inturn,XOR-edwith thelast8bytesofthemessagedataandtheresultisencryptedtoobtainH3which istheoutputofthealgorithm.

12.5AsymmetricEncryption

Asymmetricencryption,asthenameimplies,utilizestwodifferentkeys(ora keypair)forencryptionanddecryption.Theencryptionkey(aka”publickey”, seeabove)canbeusedtoencryptdataorverifyadigitalsignature.Thedecryptionkey(aka”privatekey”)canbeusedtodecryptdataorcalculateadigital signature.

Twomajorscenariosarepossibleusinganasymmetricencryptionalgorithm: oneismessageencryptionandtheotherismessagenon-repudiablesignature.To illustrateitconsiderthescenariowhenabankandaschemeeachgenerateakey pairandsharethepublicpartofthekeypairwiththecorrespondingparty.Let usdenotethebank’skeypairasKE Bank andKD Bank,andscheme’skeypairas KE Scheme andKD Scheme.ThenthebankobtainsKE Scheme,andtheschemegets KE Bank .

Assumethatthebankwantstosendasecretmessagetothescheme.For example,thebankhasencounteredissueswithsomePANsandwouldliketo securelysharethemwiththeschemesupportteamforfurtherinvestigation. Thebankalreadyhasscheme’spublickeyandcanthustakethePANs,form amessageMclear outofthem(possiblybyappendingexpletivestoindicatethe gravityofbank’ssituation)andencryptmessageMclear withKE Scheme,obtaining Menc Scheme

Asonlythecardschemepossessestherelevantprivatekey,itisthecard schemealonethatcandecipherthismessage,applyingKD Scheme toMenc Scheme toobtainMclear.

Toillustratethesecondscenarioletusassumethattheschemeissuesastatementinstructingcertainbankstolimittransactionsofaparticulartype.Aforged statementofthesortcancausemajordisruptionstopaymentservicesofmultiple bankspotentiallycausingpanicandmaybeeventriggeringabankrun.Tomake surethatwillnothappentheschemeusesitsprivatekeyKD Scheme tosignthenotificationNclear andpublishestheclear-textnotificationalongsidethesignature

Nsign Scheme.Uponreceivingthenotificationandthesignature,thebankverifies itusingKE Scheme initspossession.

Theencryptionandsignaturecanalsobecombinedinonemessage.Inthat case,forexample,thebankencryptsmessageMclear toformMenc Scheme andprovidesasignature,Msign Bank byusingKE Scheme andKD Bank,correspondingly.The twovaluesaresenttothecardscheme.ThentheschemeusesitsprivateKD Scheme toobtainMclear andthebank’spublickeyKE Bank toverifyMsign Bank .

Chapter13 PINBlockFormatsand Algorithms

CONTENTS

13.1EPB(EncryptedPINBlock)Formats ............................... 229

13.1EPB(EncryptedPINBlock)Formats

EPBorencryptedPINblockformatsaredescribedintheISO9564standard. ThereareseveraldifferentformatsofthePINblockandmanyofthemarevery similar.Formats0,1,2and3describethepackagingofaPINvalueintoa64-bit PINblock.Format4describesa128-bitPINblock.Whileformats0,1,2and3 aremeantforsomeflavorofDESencryption,Format4wasdefinedforusewith AESencryptionalgorithm.

Inallcasesthevaluesarestoredasapackedbinary-codeddecimalandthe blockssharethefollowingcommoncharacteristics:thefirstnibblealwaysspecifiestheblockformat(itcanbe0,1,2or3,seebelow)whilethesecondnibble specifiesthePINlength(andcan,therefore,varyfrom4to14,althoughPINs longerthan6digitsarenotoftenused).Therefore,agenericEPBofformats1 to3hasthestructureshownin figure13.1:HereFdenotestheformatindicator nibble,LdenotesthePINlengthandtheXvaluesaredefinedbythespecific formatofthePINblock.

Format0 isusedacrosshostswhenaPINandaPANnumberareavailable. Aformat0PINblockiscalculatedbyXOR-ingtwovectors.Forvector

Figure13.1:EPBformats0,1,2or3

1theformatindicator,thelengthandthePINarepackedasnibblesand paddedwithvalueof15(0xF)tothefulllengthof16nibbles.Forvector2 therightmost12positionsofthePANnumberwithoutthecheckdigitare takenandpaddedontheleftwith4zeroes.InthecaseofEMVtokenization(seesection4.6.3)thetokennumberisusedinsteadofthePAN.Then thevaluesareXORedandtheresultisencrypted.

Format1 isusedwhenthePANisnotavailableforsomereason.Inthatcase, theformat,lengthandPINvaluearepackedintotheblock,andtheresult ispaddedtothefull16digitswithauniquetransactionidentifierora randomnumber.

Format2 isusedforlocalcommunicationsandisofflineonly.Forinstance,in caseofanofflinePINvalidationbytheintegratedcircuitcardtheEPBis formattedusingformat2.Theformatissimilartovector1offormat0: theformatindicator(2),lengthandthePINvaluearepaddedtofullblock lengthwithvalueof15(0xF).Seesection5.3.10.5forusesofthisPIN blockformat.

Format3 isalsousedforinter-hostcommunications.Itissimilartoformat0, however,ratherthanusingconstantfillervalueof15(0xF),astringof randomvaluesfromtherangeof10to15(i.e.,hex0xAto0xF)isusedto padvector1tothefulllengthoftheblock.

Format4 isa128-bitformatdefinedtosupplantFormats0and3ininterhostcommunicationsafterperformingthetransitiontoPINencryption withAES.Thefirst8bytesoftheblockarepaddedwith0xFasinFormat0andthesecond8bytesarefilledwithrandomvaluesasincaseof Format3.

Considerthefollowingexamples.LetusassumethePANis9999990123456788 andthePINis4321.Letusalsoassumethattheuniquetransactionnumberis 750923(base10). InthatcasethePINblockslookasfollows:

Format0 Forvector1wetaketheformatindicator(0),thePINlength(4)and packthePINandpadwith0xF.Vector1lookslikefollows(PINdigitsare highlightedin bold): 044321FFFFFFFFFF.

Forvector2wetakethelast12digitsofthePANwithoutthecheck digitandleft-padthemwithzeroes.Thedigitsarehighlightedinbold. 9999990123456788.Vector2lookslikefollows: 000099901234 5678.

ThenthevaluesareXOR-ed(easytoseethefirsttwobytesarenotmodifiedbyexclusive-OR)toobtaintheblockvalueof 0443B86FEDCB A987

Format1

ThebeginningofthePINblock(first6nibbles)iscomposedofthe formatindicator,thelengthandthePINvalue.Theyshouldbepadded withauniquesequencenumberwith10morenibbles.Thehexadecimal valueofthetransactionnumberis0xB754Bandthereforethefullvalue oftheblockis 14432100000B754B

Format2 Asmentionedabove,thePINblockissimilartovector1offormat0. Theformatindicator,thelengthandthePINvaluearesimplypaddedby 0xF: 244321FFFFFFFFFF

Format3

Forvector1wetaketheformatindicator(3),thePINlength(4)and packthePINandpadwithrandomvaluesfromtherangeof0xAto0xF.

Vector1looksasfollows(PINdigitsarehighlightedinbold): 344321 AFCEDBBBAC.Forvector2wetakethelast12digitsofthePANwithoutthecheckdigitandleft-padthemwithzeroes.Thedigitsarehighlightedinbold:9999990123456788.Vector2lookslikefollows: 0000 999012345678.

ThenthevaluesareXOR-ed: 3443B83FDCEFEDD4

Format4

Forvector1theformatindicator(4)andthePINlength(4)arepadded tothelengthof16nibbleswithvalueof0xF.Theyfillouthalfofthevector’s16byteslength.Thesecondhalfofthevectorisfilledwithrandom values: 444321FFFFFFFFFFDEADBEEFDEADBEEF

Vector2carriesthePAN.Sincethelengthallowsit,thePANispackedinto thevectorfullyexceptforthecheckdigit.Thefirstnibbleofthevector indicateshowmanydigitsthereareinthePANbeyondthefirst12.

Inotherwords,afterstrippingthecheckdigitthefirstnibbleofvector2 isexactly0fora13-digitcardnumber.Foramorecommon16-digitPAN thevalueis3.

Vector2isfurtherpaddedwithzeros.Unlikeformats0to3,thevaluesare notsimplyXORed:Vector1isencryptedusingAESfirst,thenXOR-ed withvector2,thentheresultisencryptedagain(i.e.,CBCmodewitha zeroinitializationvectorisapplied).

Index

2TDES, 191 3-DES, 225 3-partyscheme, 9 3DSecure, 32,76 3DSecure2.0, 80 3DSClient, 81 3DSMethod, 83 3DSRequestor, 81 3DSRequestor-Initiated, see 3RI 3DSServer, 81 3RI, 86 3TDES, 191 4-partyscheme, 9 4DBC, see CVV accesscontrolserver, see ACS accountdata, 180 accountupdater, see accountupdater services

accountupdaterservice, 71 accountupdaterServices, 92 accountvalidation, 36 account-levelmanagement, 19 account-levelproductmanagementservice, 71 ACH, 208 acquirer, 7,8 acquirerworkerkey, see AWK,192 ACS, 78

actioncodes, 141 default, 141 denial, 141 online, 141 terminalactioncodes, 141 activationduringshopping, see ADS addressverificationservice, see AVS ADF, 104,116 ADS, 77 AEF, 112 AES, 226 AFL, 107,118,161,162 agent, 8 AID, 104,155 AIP, 107,118,127,161,162,165 AliPay, 207 allocation, 175 AmazonPayments, 207 AmericanExpress, 5,9,164 amount

additionalammounts, 69 authorizedpercycle, 22 cardholderbillingamount, 61 dataelements, 60 remainingthiscycle, 22 settlementamount, 61 transactionamount, 61 X, 131 Y, 131

AndroidPay, 31 ANSIX9.17, 192 ANSI/ISOALPHA, 215 ANSI/ISOALPHADataFormat, 20 ANSI/ISOBCD, 215

ANSI/ISOBCDDataFormat, 20 answer-to-reset, see ATR APDU, 109 C-APDU, 109 CLA, 109,110 Format 1, 111 Format 2, 111 INS, 109 P1, 109 P2, 109 R-APDU, 109 SW1, 109,112 SW2, 109,112 ApplePay, 31,206,207 applicationcryptogram, 142 AAC, 143 applicationauthenticationcryptogram, 143 ARQC, 142,143,161,162,167 authorizationrequestcryptogram, 143

calculationalgorithm, 145 TC, 143,162,167 transactioncertificate, 143 applicationcurrencycode, 131 applicationdefinitionfile, 104 applicationeffectivedate, 130 applicationelementaryfile, see AEF applicationexpirationdate, 130 applicationfilelocator, see AFL applicationidentifier, see AID applicationinterchangeprofile, see AIP

applicationprotocoldataunit, see APDU applicationselection, 107 applicationusagecontrol, 130 applicationversionnumber, 130

applicatonusagecontrol, 130 arbitration, 172,175 arbitrationchargeback, see second chargeback ARC, 147 AReq, 82 ARQC, 158 ASCII, 57,216 ASN.1, 220 asymmetricalgorithm, 224 ATC, 141,145,164 ATR, 102,109 attemptsservice, 78 authorizationresponsecode, 147 AVS, 71,87 AWK, 191,192,194

Baconcipher, 216 balanceinquiry, 37 banktransfers, 207 Base64encoding, 218 basicencodingrules, see BER-TLVencoding Baudotcode, 216 BCD, 58 BCDIC, 218 BER-TLV, see BER-TLVencoding BER-TLVencoding, 220 BER-TLVX.960, 57 BIN, 16,181 Bitcoin, 6 BKMExpress, 207 blockcipher, 224 browser-basedauthenticationflow, 83 BRSthreshold, see thresholdvaluefor biasedrandomselection

CA, 122 capture, see completion cardactionanalysis, 143 cardapplication, 101 cardmember, 6 cardnumber, see PAN cardonfile, 47

cardproduct, 15 cardproducts, 18 cardriskmanagement, 114 CardRiskManagementDataObject Lists, see CDOL1 cardscheme, 7 cardschemebranding, 14 cardsecuritycode, 19, see CVV cardsecuritynumber, 23 cardsequencenumber, see CSN cardverificationcode, see CVV cardverificationvalue, see CVV cardverificationvalues, see CVV cardholder, 6 CardholderAuthenticationVerification Value, see CAVV cardholderdata, 180 cardholderdataenvironment, see CDE cardholdername, 15 cardholderverification, 131 cardholderverificationmethods, 24,31 cashadvance, 38 cashdisbursement, see cashadvance CAVV, 80 CBC, 225 CCD, 23 CDA, 108,121,129,146,163,165, 167 CDE, 180 CDOL-Switch, 164 CDOL1, 113,115,129,144 CDOL2, 113,115,129,144 centralprocessingdate, 50 CertificationAuthorities, see CA Challengeflow, 84 chargecard, 5,17 chargecards, 18 chargeback, 172,173 chargebackacknowledgement, 172 CHD, 181 chipreader, 42 CID, see CVV cipherblockchaining, see CBC

ciphertext, 223 cleartext, 223 closed, see 3-partyscheme collaboration, 175 combination, 154 CombinationSelection, 154,155 combineddataauthentication, 108, see CDA

completenamematching, 115 completion, 36 compliance, 171,177

COMPUTECRYPTOGRAPHIC CHECKSUM, 162 consumercards, 17 contactchiptransactions, 98 contactlessmagstripe, 42,159 contactlessreader, 42 controlcharacter, 217,218 corporatecards, 17 countrycode, 22 creditcard, 18 creditcards, 18 creditfundtransfer, 38 CReq, 82 CRes, 82 cryptographiccheckdigits, see CCD CSC, see CVV CSN, 15,23 currencycode, 22 currencyexponent, 22 CVC, see CVV,26 CVK, 191 CVM

CBMconditioncode

ifmanualcash, 132 ifnocashinvolved, 132 ifovervalue, 133 ifpurchasewithcashback, 132 ifterminalsupportstheCVM, 132 ifunattendedcash, 132 ifundervalue, 133 cleartextofflinePIN, 132,137

CVMcode, 131 CVMconditioncode, 131 always, 132 CVMlist, 107,131 amountfields, 131 cardholderverificationrules, 131 example, 133 CVMresultbyte, 133 CVMresults, 133 CVR, 131 encipheredofflinePIN, 33,132, 137 encipheredofflinePINandsignature, 132 failedCVM, 33,132 mobile, 164–166 noCVM, 33,159 offlinePIN, 33 offlinePINandsignature, 132 offlinePINverification, 135 onlinePIN, 34,132,138,160 plaintextofflinePIN, 33 signature, 33,132,160 CVN, see CVV CVV, 20,21,25,191 calculationalgorithm, 26 CVC3, 162 CVV1, 26,28 CVV2, 26,29 CVV3, 30 dCVV, 26,30,162,166 DynamicCVV, 30 iCVV, 26,29 cycle begin, 22 length, 22

dataauthenticationinputvector, 126 dataencryptionkey, 190, see DEK dataintegrityservices, 70 datakey, see DK dataobjectlist, see DOL datastorage, 161

IDS, 161,163,164 SDS, 161 DDA, 121 DDF, 116 DDOL, 113,128 debitcard, 18 debitcards, 18 deciphering, 223 Decoupledflow, 84 decryption, 223 dedicatedfile, 101,104 DEK, 90,192 delayeddebitcard, see chargecard deposit, 38 DES, 225 DF, see dedicatedfile DFname, see AID digitalwallet, see e-wallet DinersClub, 5,9 directapplicationselection, 115,116, 156 DirectoryServer, 78 Discover, 5,9,166 discretionarydata, 20,21,23 disputearbitration, 171,172 disputes, 171,172 DK, 192 DMS, 49 DOL, 113 DorotheaParry, 19 dualmessageservice, see DMS dynamicdataauthentication, see DDA DynamicDataAuthenticationData ObjectList, see DDOL

e-commerceindicator, see ECI e-wallet, 205 pass-through, 205,206 staged, 205,206 EBCDIC, 57,217 ECB, 225 ECHO, 166 ECI, 80

ecommerce, 46 EF, see elementaryfile Efecty, 207 electroniccodebook, see ECB electronicwallet, see e-wallet elementaryfile, 101,104 cyclic, 106 internal, 106 linearfixed, 106 linearvariable, 106 transparent, 106 working, 106 EMV, 6 full-grade, 29,31 part-grade, 29,31 EMV3DSecure, 80 EMV3DS2.0, 32 EMVcard, see ICC EMVcontact, 40 EMVcontactless, 40,129,151 EMVtags

4F, 116 5A, 120 5F24, 120,131 5F28, 130 5F2A, 144 5F2D, 117 5F55, 130 5F56, 130 6F, 116 8C, 120,144 8D, 120,144 8E, 120,131 8F, 125,127–129 9A, 144,147 9C, 144 9D, 115,116 9F02, 144 9F03, 144 9F08, 130 9F0D, 141 9F0E, 141 9F0F, 141

9F11, 117 9F12, 117 9F13, 141 9F14, 140 9F17, 136 9F18, 148 9F1A, 144 9F23, 140 9F26, 146 9F27, 146 9F2D, 137 9F2E, 137 9F2F, 137 9F32, 127–129 9F34, 133 9F36, 141,145,146 9F37, 128,137,144 9F38, 118 9F42, 114,131 9F46, 128,129,137 9F47, 128,129,137 9F48, 128,129,137 9F49, 127 9F4A, 127 9F4B, 146 9F4C, 128 9F5C, 166 9F60, 165 9F66, 163 9F6C, 163 9F7E, 166 61,115 70,112,114,120 71,148,165 72,148 77,114,118,128,146 80,118,128,146 82,118,145 83,118 86,148 87,117 90,127–129 91,147,148

92,127–129

93,127 94,118 95,144 97,145 98,145 A5, 117

Amount,Authorized, 144

Amount,Other, 144

ApplicationCryptogram, 146

ApplicationCurrencyCode, 114, 131

ApplicationExpirationDate, 131

ApplicationExpiryDate, 120

ApplicationInterchangeProfile, 145

ApplicationPreferredName, 117

ApplicationPrimaryAccountNumber(PAN), 120

ApplicationPriorityIndicator, 117

ApplicationTransactionCounter, 145

ApplicationTransactionCounter (ATC), 141,146

ApplicationUsageControl, 130

ApplicationVersionNumber, 130

AuthorizationResponseCode, 147

CardRiskManagementDataObjectList 1, 120

CardRiskManagementDataObjectList 2, 120

CardTransactionQualifiers, 163

CardholderVerificationMethod (CVM)List, 120

CardholderVerificationMethod (CVM)Results, 133

CardholderVerificationMethod List(CVMList), 131

CertificationAuthorityPublicKey Index, 125,127–129

CryptogramInformationData(CID), 146

DynamicCardVerificationValue (DCVV), 166

DynamicDataAuthenticationData ObjectList(DDOL), 127

ICCDynamicData, 128

ICCPublicKeyCertificate, 128, 129,137

ICCPublicKeyExponent, 128, 129,137

ICCPublicKeyRemainder, 128, 129,137

IntegratedCircuitCard(ICC)PIN EnciphermentPublicKeyCertificate, 137

IntegratedCircuitCard(ICC)PIN EnciphermentPublicKeyExponent, 137 IntegratedCircuitCard(ICC)PIN EnciphermentPublicKeyRemainder, 137

IssuerActionCode-Default, 141 IssuerActionCode-Denial, 141 IssuerActionCode-Online, 141

IssuerAuthenticationData, 147, 148

IssuerCodeTableIndex, 117 IssuerCountryCode, 130

IssuerPublicKeyCertificate, 127–129

IssuerPublicKeyExponent, 127–129

IssuerPublicKeyRemainder, 127–129

IssuerScriptCommand, 148 IssuerScriptIdentifier, 148 IssuerScriptTemplate 1, 148,165 IssuerScriptTemplate 2, 148

IssuerUpdateParameter, 165

Languagepreference, 117

LastOnlineApplicationTransactionCounter(ATC)Register, 141

LowerConsecutiveOfflineLimit, 140

MagstripeDataObjectList, 166 PersonalIdentificationNumber (PIN)TryCounter, 136

ProcessingOptionsDataList(PDOL), 118

READRECORDResponseMessageTemplate, 120

ResponseMessageTemplateFormat 1, 128,146

ResponseMessageTemplateFormat 2, 128,146 SignedDynamicApplicationData, 146

SignedStaticApplicationData, 127 StaticDataAuthenticationTag List, 127

TerminalCountryCode, 144 TerminalTransactionQualifiers, 163

TerminalVerificationResults, 144

TransactionCertificate(TC)Hash Value, 145

TransactionCertificateDataObjectList(TDOL), 145

TransactionCurrencyCode, 144 TransactionDate, 144 TransactionType, 144 UnpredictableNumber, 128,137, 144

UpperConsecutiveOfflineLimit, 140 EMVTokenization, 92 EMVCo, 6 encipher, 223 encrypt, 223 encryptedPINblock, see EPB eNETS, 208 entrymode, see POSentrymode EntryPoint, 154 StartA, 154,155

StartB, 154,155,163,165,167 StartC, 154–156 StartD, 154 EPB, 34,191,194,226,229 format0, 229 format 1, 229 format 2, 229 format 4, 229 ESAPAY, 207 Europay, 5 expirydate, 15,21,23 EXTENDEDGPO, 164

EXTERNALAUTHENTICATE, 108, 143,147,163

fastDDA, see fDDA Faster, 208 Fawry, 207 FCI, 117,163 fDDA, 129,161,163,167 FID, 104 FIDpath, 105 filecontrolinformation, see FCI finalapplicationselection, 117 FinalOutcome, 153,154 FIPS, 197,225 FIPS 140-2,195 FirstSupper, 5 fixedfileidentifier, see FID floorlimit, 138,139 Flooz, 207

FNBCellPayPoint, 207 formatcode, 22 ForrestParry, 19 fraudpreventionservices, 70 fulfillment, 172,173 fullnamematching, 115 funddisbursements, 38 fundingtransaction, 39

GAC, 108

GENERATEAC, 108,113,115,129, 142,144,146,161–164

firstGAC, 108,129,143,157, 158,164,165

secondGAC, 108,129,144,147, 157,158,165

generationofcryptograms, see GENERATEAC GETCHALLENGE, 136,137 GETDATA, 141,162,164

GETMAGSTRIPEDATA, 166 GETPROCESSINGOPTIONS, 113, 118,161–164,166,167

hardwaresecuritymodule, see HSM HSM, 28,35,180,187,190,191,193, 194,202

IAN, 16 ICC, 99 ICCdata, 40 iDEAL, 208 IIN, see BIN indirectapplicationselection, 115,116, 156

initializationvector, 225 initiateprocessing, 118 initiatingapplicationprocessing, 107 installmenttransaction, 47 integratedchip, 15 interchange bilateral, 23 international, 23 national, 23 interchangecontrols, 23 interchangefees, 10

INTERNALAUTHENTICATE, 113, 128,161,163–165

internationalAIDregistration, 105 iPhone, 206 ISO, 8 ISO13491, 197 ISO3166-1, 106 ISO4217, 60,114 ISO8583, 50

ISO8583message, 51 additionalamounts, 69 advice, 53 adviceresponse, 53 amounts, 60 authorization, 53 authorizationcode, 67 bitmap, 51,55 cardacceptornameandlocation, 69 cardsequencenumber, 65 conversionrates, 61 dataelements, 51,56 datafields, 51 EPB, 69 expirationdate, 63 extendedbitmap, 55 financial, 53 header, 51 ICCdata, 69 localtimeanddate, 62 merchantID, 68 merchanttype, 63 messageclass, 52 messagefunction, 52 MID, 68 MTID, 51 networkmanagement, 53 PINblock, 69 POSconditioncode, 66 POSentrymode, 64 primarybitmap, 55 processingcode, 60 rejectcode, 52 request, 53 requestresponse, 53 responsecode, 67 RetrievalReferenceNumber, 66 reversal, 53 RRN, 66 secondarybitmap, 55 STAN, 62 terminalID, 68

tertiarybitmap, 55 TID, 68 Track1data, 69 Track2data, 66 Track3data, 66 transmissiondateandtime, 61 ISO9562, 229 ISO9564, 137 ISOdialect, 51 ISO/IEC14443, 14,104,152,153 ISO/IEC15693, 152 ISO/IEC4909, 20,22 ISO/IEC7811, 15,19 ISO/IEC7812, 16 ISO/IEC7812-1, 211 ISO/IEC7813, 14,20 ISO/IEC7814-4, 104 ISO/IEC7814-5, 105 ISO/IEC7816, 14,99,108,110,152 ISO/IEC7816-3, 108 ISO/IEC7816-4, 106,111,112 ISO/IEC7816-5, 105 ISO/IEC9564, 33,34 issuer, 7,8 issuerauthentication, 114,142 issuerscript, 108 issuerscriptprocessing, 114 issuerworkerkey, see IWK ITA2, 216 IWK, 192

J/Secure, see 3DSecure JapanCreditBureau, 5 JavaCard, 100 JCB, 5,161,165 JIS-T, see magneticstripe JIS-U, 20 JSON, 81 julianday, 66 JWE, 81 KCV, 195,213 KEK, 35,190,192,194 Kernel, 30,153

Kernel 1, 161 Kernel 2, 161 Kernel 3, 163 Kernel 4, 164 Kernel 5, 165 Kernel 6, 166 Kernel 7, 167 KernelActivation, 154,156 key, 224 keyblock, 192 keyceremony, 201 keycertificate, 124 keycheckvalue, see KCV keycomponents, 194 keycustodian, 201 keyencryptingkeymaster, see KKM keyencryptionkey, see KEK keyentry, 42 keypair, 227 keyrecovery, 124 keyremainder, 124 KKM, 192

liabilityshift, 176 LMK, 90,190,192,202 localmasterkey, see LMK longitudinalredundancycheck, 21,23, see LRC LRC, 212 Luhnalgorithm, 16,211

MAC, 111,145,224,226 Maestro, 5 magneticstripe, 19 magstripe, see magneticstripe, 42 magstripefallback, 101 marketplace, 8 masterfile, 104 masterfilekey, see LMK masterkey, 192 MasterCard, 5,161 MasterPass, 207 maximumtargetpercentagetobeused forrandomselection, 140

MDOL, 166 merchant, 6 MerchantPlug-In, see MPI merchant-initiatedtransaction, 46,86 messageauthenticationcode, see MAC MF, see masterfile MFK, see LMK,192 MII, see BIN Mir, 6 mobileauthentication, 32 mobilepayments, 93 mobilePOS, see mPOS moneytransfers, 39 MOTO, 46 mailorder, 46 telephonyorder, 46 MPI, 78 mPIN, 32 mPOS, 43 nationalAIDregistration, 106 NFC, 104,206 NIST, 226 non-fulfillment, 172,173 NSPK, 5 offlineauthorization, 138 offlinecardauthentication, 107,120 offlinedataauthentication, 114 one-wayhash, 224 open, see 4-partyscheme originalcredit, 38 Osaifu-Keitai, 206 Outcome, 154 OutcomeProcessing, 154,156 Outcomes

Approved, 157 Declined, 157 EndApplication, 158,165 OnlineRequest, 158 SelectNext, 157 TryAgain, 166,167

TryAnotherInterface, 158 Oyster, 100

PAN, 15,20–22,59 PANservicerestrictions, 23 partialnamematching, 115 password one-time, 32 static, 32 payee, 7 payer, 7

PaymentApplicationDataSecurity Standard, 180

PaymentCardIndustryDataSecurity Standard, see PCIDSS PaymentCardIndustrySecurityStandardsCouncil, see PCISSC PaymentNetworkTokenization, see EMVTokenization

paymentnetworktokenizationservice, 71 PaymentServicesProvider, 8 PaymentSystemEnvironment, see PSE paymenttransaction, 38 PayPal, 206 PCIDSS, 29,180,181,191 AOC, 181

ApprovedScanningVendor, 182 ASV, 182

AttestationofCompliance, 181 levelofcompliance, 181 QSA, 181 QualifiedSecurityAuditor, 181 ReportofCompliance, 181 ROC, 181 SAQ, 181 SAQA, 182 SAQA-EP, 182 SAQB, 182 SAQB-IP, 182 SAQC, 182 SAQC-VT, 182 SAQD, 182 SAQP2PE, 182 Self-AssessmentQuestionnaire, 181

PCIPADSS, 180,186

PCIPTS, 45,180,197,226

PCISSC, 180

PDOL, 113,118,129,163,165,166

PED, 39,44

PEK, 35,192 PICC, 104 PIN, 10

PINblock, 229

PINcontrolparameters, 22

PINencryptionkey, see PEK,192

PINentrydevice, see PED

PINTransactionSecurity, see PCIPTS,180

PINtranslation, 191,194

PINverificationkey, see PVK

PINverificationvalue, 21, see PVV

PIX, 105 plaintext, 223 POSentrymode, 45 contactlesschip, 65 contactlessmagstripe, 65 eCommerce, 65 ICCread, 65 keyentry, 64 magstripefallback, 64 magstriperead, 64 manual, 64 noterminalused, 64 unknown, 64 POSsystem, 153 PPSE, 156 pre-arbitration, 172,176 pre-authorization, 36 pre-compliance, 177 Pre-Processing, 154,155 pre-processing, 154 prepaidcard, 18 prepaidcards, 18 PReq, 82 PRes, 82 processingday, 50

ProcessingOptionsDataObjectList, see PDOL

processingrestrictions, 130 processortokenization, 89 proprietaryapplicationidentifierextension, see PIX ProtocolActivation, 154,155 ProximityIntegratedCircuitCard, see PICC

ProximityPaymentSystemEnvironment, see PPSE PSE, 107,115 PSP, 8, see PaymentServicesProvider purchase, 36 purchasewithcashback, 37 PUTDATA, 162 PVK, 35 PVKI, 21 PVV, see PINverificationvalue,35 quasi-cash, 36 randomtransactionselection, 138,139 readapplicationdata, 120,166 READRECORD, 114,115,120,161–164,166,167 RECOVERAC, 162 recurringpaymentrevocationservice, 71 recurringtransaction, 47 refund, 36 registeredapplicationprovideridentifier, see RID registrationcategory, 105 relaymarker, 23 representment, 172–174 retrievalrequest, 172 retrycount, 22 reversal, 37 full, 37 partial, 37 revocationofauthorization, 92 RFC7516, 81 RFID, 104 RID, 105 Rijndael, 226

risk-basedauthentication, 80 RReq, 83 RRes, 83 RST, 102,109 RuPay, 5 SafeKey, see 3DSecure salesdraft, 173 SamsungPay, 31,207 SAN, 23 SANservicerestrictions, 23 SCA, 34 scriptprocessing, 148 SDA, 114,121,127 SDKEncryptedDataelement, 87 secondchargeback, 172,175 secondpresentment, see representment SecureCode, see 3DSecure SELECT, 115,161,162,166 SelectNext, 156 sensitiveauthenticationdata, 180 SEPADD, 208 servicecode, 21,23 SET, 77 settlementservice, 50,70 SFI, 106,112 shortfileidentifier, see SFI signaturestrip, 19 singlemessageservice, see SMS Skrill, 206 smartcard, 99 SMS, 49 SSC, see PCISSC SSL, 76 stand-inprocessing, 28,70 stand-inservice, 78 standingauthorization, 46 standingorder, 46 staticdataauthentication, see SDA STIP, 70 stored-valuecard, see prepaidcards streamcipher, 224

strongcustomerauthentication, see SCA sub-draft, see substitutiondraft subsidiaryaccountnumber, see SAN substitutedraft, 175 substitutiondraft, 173 symmetricalgorithm, 224 targetpercentagetobeusedforrandom selection, 140 TDOL, 113,145 technologyselection, 101 Telcobilling, 207 terminal attended, 43 cardholder-activated, 43 unattended, 43 terminalactionanalysis, 108,141 terminalapplication, 101 terminalriskmanagement, 108,114, 138

TerminalVerificationResult, see TVR thresholdvalueforbiasedrandomselection,139

TLS, 76 TLV, 220 Track 1, 20,40,159,166 Track 2, 20,21,40,159,166 Track 3, 20,22

TransactionCertificateDataObject List, see TDOL transactioncertificatehashvalue, 145 transactioncompletion, 149 TransactionStatusInformation, see TSI

TransFort, see 3DSecure Troika, 100,153 trustzone, 193 TSI, 107,114,122,133 TVR, 107,108,114,122,130,133, 135,138,139,141,142,148

TypeAPICC, 104 TypeBPICC, 104

UCAF, 80 UnionPay, 167 unique, 36

UniversalCardholderAuthentication Field, see UCAF unpredictablenumber, 128

velocitychecking, 138,140 VerifiedByVisa, see 3DSecure VERIFY, 136,137 Visa, 5,161,163

VisaCheckout, 207 voiceauthorization, 67

WebMoney, 206 WeChatPay, 206,207 withdrawal, 38

ZMK, 192–194,202 zonemasterkey, see ZMK zonePINkey, see ZPK ZPK, 192,194