APPLE PAY
FRAU
GUIDELINE
February 2021
Apple Pay EMEIA Fraud Readiness Guidelines 1
Introduction
Traditionally, card fraud has involved cloning cards for use at ATMs or in retail stores or
using compromised card details to shop online. The introduction of Chip/PIN resulted in
the majority of card fraud moving towards the Card Not Present environment.
With Apple Pay, fraudsters attempt to pass the issuer’s security process to add
compromised card details to Apple Wallet. If successful, they can spend in physical retail
or online stores with the immediate acquisition of goods or services. This brings new
challenges to issuers to ensure the individuals adding cards to Wallet are truly their
cardholders.
As this creates a new opportunity for fraud in both card-present and card not present
environments, issuers must treat provisioning as a high-risk transaction and ensure steps
are taken to approve provisioning only from the authorised user
According to the international Payment Networks, fraud on Apple Pay is lower than on
cards, however, partners must continue to use systems to detect and prevent possible
fraud
Whilst reported fraud is low, it is still an attractive target for criminal activity and this
document outlines the latest fraud best practices for Apple Pay but is not exhaustive as
fraud continues to migrate
Apple Pay EMEIA Fraud Readiness Guidelines 2
.
Authentication
The best opportunity to prevent fraud is during provisioning and authenticating the
authorised user of the card.
Experience has shown that weaker authentication channels and methods result in
increased exposure to fraud
Examples of weak authentication channels include
• Inbound call centr
• Pro le-based authentication questions e.g. date of birth, cardholder address, mother’s
maiden nam
• Outbound contact (including OTP) to recently changed contact detail
Examples of strong authentication methods include
• Authentication through a mobile banking ap
• One Time Passcode (OTP) by SMS to trusted or tenured mobile phone number
• EMV Chip/PIN to generate an OT
• Outbound contact with a trusted or tenured phone numbe
• Voice and line recognition on inbound call
Whilst SMS OTP is recognised as the most secure channel for user authentication, it is still
an attractive target for criminal activity but Apple’s risk data can help issuers to identify
Phishing
Apple Pay EMEIA Fraud Readiness Guidelines 3
fi
.
App Provisioning / Veri cation
Provisioning or verifying through the issuer’s Mobile Banking App is the preferred
authentication method, not only from a security perspective, but also for customer
experience. Customers who provision their card through their bank’s Mobile Banking App
are more likely to complete the process of adding their card to Wallet
As a general rule, provisioning a card to Apple Pay should require the same level of
security as setting up a new payee and transferring funds within the app
• Registering a new installation of the app should require multi-factor authenticatio
• Regular log-in should require strong authentication (e.g. Touch ID/Face ID
• Device recognition is recommended to establish trus
• App tenure to a devic
There is still risk of malicious in-app provisioning through phishing but Apple’s risk data
can help the issuer detect this and respond appropriately
SMS OTP
SMS OTP is also a preferred authentication method, however due care should be taken to
prevent fraud on this channel
Phone number changes
SMS OTP should be avoided as a form of authentication if the mobile phone number has
been changed recently, unless strong multi-factor authentication has been used to update
the details
The OTP messages should always clearly state the purpose of the message and include
anti-phishing statements:
Example: To register your card ending 1234 for Apple Pay on your iPhone, enter code
123456. Your bank will never ask you to reveal this cod
Incorrect entries should be monitored to detect attackers trying to guess the OTP through
multiple attempts. In addition, we suggest checking the phone number linked to the device
(attempting the provision) to the phone number that the bank is dispatching the OTP
Apple Pay EMEIA Fraud Readiness Guidelines 4
.
fi
Call Centre Activatio
• Activation by call centre should not be provided as the default method and only offered
when a user has no alternative metho
• Call centre shall not be displayed in Wallet as a veri cation option if other methods are
available to the customer (e.g. if the mobile number is on le
• If customers call to activate their token, support should rst be offered to assist with the
OTP or in-app proces
• Provision attempts with a high-risk fraud indicator (e.g. 0G reason code / Orange path)
must be transferred to a specialised fraud team for enhanced security and screenin
• Fraudsters may call multiple times to attempt to answer security questions. There must
be a process in place to identify multiple calls and block subsequent provision attempt
• Where possible, use caller line identi cation (CLI) or voice recognition technology to
match the customer record as an additional veri cation ste
Dynamic account and transaction-based questions are recommended
• Questions relating to speci c transactions e.g. amount of last ATM withdrawal, name of
the merchant for transaction yesterday of €x amoun
• Questions relating to direct debits or standing orders e.g. mobile phone carrier and
usual payment amount, mortgage payment
• Questions relating to other products with the bank e.g. credit card / loan balance and
monthly repayment amoun
Apple Pay EMEIA Fraud Readiness Guidelines 5
s
fi
t
fi
s
fi
t
fi
fi
fi
p
Apple Provisioning Data
Apple provides data at the time of provisioning to help determine what level of user
authentication is necessary to provision a card. This data includes risk indicators which are
compiled through multiple data sources across Apple and have proven predictive in
determining the likelihood of fraud.
The data elements that Apple provide work well when combined with issuer account data
at the time of provisioning to assist with the decision process. These data elements
provide information about the Apple ID and device being used for provisioning.
Colour Recommendatio
Apple provides a colour recommendation at the time of provisioning to support Issuer to
identify risk.
• A ‘Green’ recommendation indicates that the provisioning attempt is trusted by Apple
based on the customer’s Apple ID activity and device history.
• A ‘Yellow’ recommendation indicates that the customer, card or device is unknown to
Apple or that one or more risk indicators have been triggered. Yellow can range between
low to medium risk and it is recommended to review the Apple data to understand the
reasons for Yellow.
• An ‘Orange’ recommendation indicates that the provisioning attempt has triggered
Apple’s high-risk model and extra care should be taken when authenticating the
customer. Apple does not decline requests even on known fraudulent devices. An
‘Orange’ recommendation is re ected by ‘0G’ being present in the reason codes.
Apple Pay EMEIA Fraud Readiness Guidelines 6
fl
Reason Code
When a card is added to Apple Pay, Apple will send a number of data points and reason
codes to the Payment Network. Issuers must follow up directly with their Payment Network
or Service Provider to con rm which data elements will be made available to them and
what formats / values to expect
The Reason Code eld is a string of Apple risk indicators triggered at the time of provision
The highest risk Reason Code is 0G. This means that the provision has triggered Apple’s
Orange Path fraud model and should go through enhanced security. The Orange Path
model is regularly retrained using Apple Pay fraud data and has proven to be effective at
detecting high-risk activity. Apple recommends that all call centre activation attempts with a
0G reason code be subject to manual review by trained fraud agents and declined where
fraud is suspected
The full list of reason codes used by Apple are in the following table
Reason Code Description
01 Apple ID too new relative to launch
02 Apple ID too new relative to provisioning request
03 Apple ID / card pair is newer than date threshold
04 Changes made to the account data within the date threshold
05 Suspicious transaction linked to this account
06 The account has not had activity in the last year
07 Suspended cards in the secure element
08 The device was in lost mode in the last 7 days for longer than the duration threshold
09 The number of provisioning attempts on this device in 72 hours exceeds the threshold
0A Excessive number of different cards attempted at provisioning to this phone in 24 hours
0B Provisioning request contains a distinct name in excess of the permitted threshold
0C deviceScore is less than 3
0D accountScore is less than 4
0E Device provisioning location outside of iTunes home country
0F Model rules not available at this time (in cases where back end systems time out)
0G Device is considered high risk provision (orange ow) per Apple data
Apple Pay EMEIA Fraud Readiness Guidelines 7
.
fi
s
fi
.
fl
.
Data Elements Tabl
The following table shows all data elements provided by Apple at the time of provisioning
Data Elements Description
fpan Account holders PAN
billingAddress, billingZip Address and Zip code on le with iTunes that is available for the PAN
expirationDate, CVV Expiration date and CVV of the PAN
cardHolderName Card holder name
accountIdHash Hash that represents the account ID (iCloud account)
deviceAcceptLanguage Language setting of the device
SEID Secure element ID used to identify the device the card is being provisioned on
deviceType 1=iPhone, 2=iPad, 3=watch, 4 = Mac
extensiveDeviceLocation Latitude/longitude, e.g. +37.23/-121.23
fullDeviceNumber Full phone number of the device if it is a phone or a watch paired with a phone
deviceName Name the user has created for the device
sourceIp IP of the device when provisioning
fpanSource Indicator as to the source of the fpan: on- le, banking app, or user entered
color Color recommendation (green, yellow, orange)
deviceScore Score from 1 to 5 where 5 is most trusted, 3 is unknown, 1 is known fraud
accountScore Score from 1 to 5 where 5 is most trusted, 3 is unknown, 1 is known fraud
phoneNumberScore Score from 2 to 5 where 5 is most trusted, 3 is unknown,
captureMethod Indicator for the capture method used (1 - camera, 2 - manual)
The data elements can be used by an issuer to check consistency against the issuer’s
user pro le and look for inconsistencies between the data. The colour recommendation
and data elements, combined with issuer data can be used to determine the appropriate
decision
When the device score equals 1, it con rms that the device has been previously reported
fraudulent or shares some pro les with other data points linked to fraud. Apple requires
provisions with a device score of 1 to be automatically red owed and declined by the
issuer.
Apple Pay EMEIA Fraud Readiness Guidelines 8
fi
.
fi
fi
e
fi
fi
fl
.
Postive Indicator
Some data elements can be used as ‘positive’ indicators when combined with data held by
the issuer
• Colour = Gree
• Full Device Number matches mobile number from issuer customer recor
• Device accept-language matches the issuer’s customer pro l
• The Apple ID/Device name correlates with the card nam
• The device location/IP address is consistent with the issuer’s pro l
Unsuccessful Provision
Whilst the focus is on successful provisions, it is also an opportunity for issuers to use data
from unsuccessful attempts to identify possible card compromises or Phishing. Examples
issuers can use
• Excessive attempts to add a card with incorrect expiry dates or CV
• Excessive attempts to add a card with invalid OTP
• Multiple cards belonging to different customers linked to the same SEI
• Attempts to activate through Call Centre and failing ID&
• Attempts to activate through call centre where better alternatives exist (e.g. SMS OTP
Mandatory Rule
The following rules are mandatory under the Issuer agreement with Apple. Any exception
to these must be approved in writing by an Apple representative
• If the device score equals 1 the provisioning request must be declined
• If the issuer has red owed a provision and the customer has successfully veri ed them-
self through strong customer authentication, the issuer MUST send Apple the SEID to
apple-pay-fraud-reporting@[Link] to reset the device’s risk pro le. We are
aware in some cases, fraudsters may add their legitimate card onto Apple Pay to get
their deny status changed, as such we ask for additional care when requesting deny list
removal
• If the following reason codes are present together 0G, 0B, 03, (either 01 or 04), either
(09 or 0A) the issuer must decline request
Apple Pay EMEIA Fraud Readiness Guidelines 9
I
fl
s
fi
e
fi
e
fi
fi
)
• If Apple recommends Orange (0G Reason code is present) and the user successfully
completes authentication through a strong method, the issuer must monitor early life
transactions. Orange recommendations should not be authenticated through less secure
methods e.g. inbound call centre
• Issuers must create their own additional rules to support the foundational mandatory
requirements.
Transaction Monitoring
If a card is provisioned fraudulently on Apple Pay, transactional fraud tends to take place
very quickly after the token has been activated. It is recommended to utilise data
associated with the provision, the token and the transaction to detect high-risk transactions
on Apple Pay and
• Distinguish between Apple Pay transactions and regular contactless card transaction
• Use transactions on card and Apple Pay to look for unusual variatio
• Monitor transactions at the token leve
• Use the timestamp of the provision
• Looking for E-commerce transactions on tokens, not through Apple Pa
• Create an issuer risk assessment / score based on Apple data + issuer data at the time
of provisionin
Example: High-value transaction at a high-risk MCC, where the token was activated within
the last 2 hours and the provision was agged as high ris
1st Party Fraud
Whilst the focus of this document is on hostile fraud it should be kept in mind that some
reported fraud was approved or facilitated by the authorised user
Issuer’s chargeback teams should use information regarding provisioning and transactions
on token and cards to attempt to link the transaction to the user.
Apple Pay EMEIA Fraud Readiness Guidelines 10
g
fl
k
Reporting
When fraud is identi ed on Apple Pay, the token must be deleted promptly and the
compromised card blocked and reissued.
Apple provides a method to report devices that were used to commit fraud. Issuers are
required to send the SEID of an account provisioned that has been con rmed fraudulent to
Apple. Apple processes these SEIDs on the same day and returns a Device Score of 1 on
all subsequent provision attempts on that device.
All issuers across the world actively engage in reporting SEIDs and it is a way issuers can
collaborate to avoid fraud.
You must promptly report fraudulent SEIDs to apple-pay-fraud-
reporting@[Link]
If you cannot locate the SEID, please refer to the speci cations from the Payment
Networks to understand where this is available. It is a mandatory requirement that issuers
receive and store the SEID linked to the FPAN
In addition to reporting individual devices, issuers are contractually required to include
aggregate fraud data by both volume and value in the monthly issuer performance report.
The reports help Apple measure the integrity of the platform and identify partners that
require additional support
Please see an extract of the fraud section of the issuer performance report below.
Apple Pay EMEIA Fraud Readiness Guidelines 11
fi
.
fi
fi
Fraud Readiness Checklist
In preparation for launch, issuers are asked to present on the below topics:
Apple data available for provision decisio
Orange / Yellow / Green recommendation policy de ned
Rules de ned around Apple and bank dat
Authentication channels and hierarchy supporte
“Anti-phishing” statement added to SMS OT
Step-up authentication for Orange path call centre provision
Early life transaction monitoring de ned
Case management process for con rmed fraud
Process for promptly reporting fraudulent SEIDs to Appl
Fraud losses to be included in the monthly reportin
Additionally, pre-paid issuers will be asked to present on the following
KYC processes for account openin
Risk controls for account top-ups
Apple Pay EMEIA Fraud Readiness Guidelines 12
fi
fi
g
fi
fi
e
