Mandates

This section of the website contains information on all card scheme updates and mandates, if you require more information on how this may apply to you please get in touch with our support team using the credentials below.

 

If you need to speak to a member of the team directly, please call 01248 672050 or email [email protected].

Mandates

Currency mandate - Chilean Peso/Ugandan Shilling - October 17

Effective 13 October 2017, Visa and Mastercard have changed currency exponent values for Chilean peso and Ugandan shilling to align with ISO standards and other card schemes. This change will help to eliminate false declines or at-risk approvals caused by differences in currency exponent values.

This new mandate requires transactions denominated in Chilean peso and Ugandan shilling to be submitted using zero minor units instead of two minor units as they are currently submitted.

Furthermore, Visa is introducing a new three-digit alpha country code “TKL” for the country of Tokelau

E-commerce Turkish Regulation - December 2017

Effective 31 December 2017, a new local e-commerce regulation published by the Banking Regulations and Supervision Agency (BRSA) will require issuers in Turkey to obtain consent from their cardholders to enable cards to perform e-commerce transactions. Turkish issuers are also required to decline any e-commerce transactions attempted with cards for which cardholders have not yet provided consent. In light of that, merchants are encouraged to invite cardholders to contact their issuer to ensure their card is enabled for e-commerce transactions.

Furthermore, to ensure that declines are handled properly, issuers in Turkey should use Decline Response Code 93—Transaction Cannot Be Completed: Violation of Law when declining an e-commerce transaction on a card that has not received consent for this type of transaction from the cardholder. And when receiving Decline Response Code 93 for an e-commerce transaction attempted with a Turkey-issued card, all merchants should provide the following message to their customers: “Contact your card issuer to enable your card for e-commerce transactions.”

Moreover, when receiving all other decline response codes (with the exception of Decline Response Code 51—Insufficient Funds) for Turkey-issued card transactions, merchants should modify their general decline message to specify that the decline may be due to the new block because it is possible that not all issuers will be able to comply with the Visa decline response code recommendation.

Visa update - brute force autorisation attacks

Visa have shared recommended best practices to prevent brute-force authorisation attacks.

In a brute-force attack fraudsters use automated software known as “botnet” which continuously attempts to guess account data such as account number, card expiration date, PIN or Card Verification Value 2 (CVV2), as well as a user password for online account access, until a positive authorisation response is returned.

In order to help prevent this kind of fraud, Visa recommends that merchants apply the following best practices:

Real-time fraud detection:

  • Where available, use a layered validation approach that employs CVV2 and Address Verification Service (AVS).
  • All online merchants should manage fraud-detection systems that support device fingerprint, email validation and botnet detection.
  • Analyse time zone differences and browser language consistency from the cardholder’s IP address and device. A transaction may be classified as a higher risk and be sent for manual review instead of bypassing the automatic approval process.
  • Look for multiple tracking elements in a purchase linked to the same device. For example, multiple transactions with different cards, using the same email address and same device ID, may be a trigger for fraud classification or review.
  • Look for logins for a single card account coming from multiple IP addresses.
  • Look for excessive usage and bandwidth consumption from a single user.
  • Review logins with suspicious passwords that hackers commonly use. For example, today some merchants are detecting fraud based on a grey list with set passwords or combinations of passwords commonly used in fraudulent transactions.
  • Payment gateways should implement tracking rules to alert simultaneous transactions testing with low amounts at the merchant ID level.

Front-end controls:

  • Consider using Three-Domain Secure (3DS) authentication and captcha controls to prevent automated transaction initiation by robots or scripts (for example, five authorizations from one IP address or card).
  • Lock out an account if a user guesses the user name / password and any account authentication data incorrectly on “x” number login attempts.
  • Inject random pauses when checking a card to slow a brute-force attack that is normally dependent on time. This can be done on certain Bank Identification Numbers (BINs) that have been determined to have a high fraud incidence.
  • Include IP address with multiple failed card payment data in a fraud detection’s black-list database for manual review.
  • In addition to velocity checks for small and large transactions, use velocity checks for low amounts or authorization-only transactions.

Analytics:

Create a Management Information System (MIS) or report based on “Invalid Account Number” fraud detection attempts at the issuer BIN level, the account number or terminal ID level, or the IP address or device ID level.

Please speak to our support team regarding our suite of fraud solutions