7. Compliance
Compliance is the state of being in accordance with established guidelines or specifications. Members of NCHL duly fulfill the pre-requisites, integration compliances and implementation compliances.
7.1 Acquirer Compliance
The following section describes various compliances required for acquirers.
7.1.1 General Compliances
• Message sent to NCHL must be structured as per this integration specification.
• Acquirer must not store any sensitive cardholder data from the transaction like PIN, OTP, track data, expiry date and CVV1 / CVV2.
• Acquirer must take care for configuring the terminals correctly i.e. TID, MID, MCC, location, date and time, country code etc.
• Acquirer shall generate reversal for the transaction for which the late good response is received by acquirer.
• Suspected reversals should not be forwarded by Acquirer to NCHL.
• Acquirer should not support partial dispense.
• In some situations, when NCHL encounters a format error with the request message sent by acquirer, NCHL will send a decline message to acquirer. No reversal needs to be generated by the acquirer for such declined message of format error.
Transaction Compliances
Various transactions have different compliance requirements as mentioned hereafter.
7.1.2.1 Purchase Transaction
• For Card present transactions, track 2 data or track 1 data must be present.
• For purchase with cash back transactions, transaction amount should be present in DE - 4 and cash back amount should be present in DE - 54. The value of DE - 54 should be less than DE - 4.
• For Card not present (CNP) transactions, DE - 14 is mandatory.
• For chip based transactions, DE - 55 (all mandatory tags) and DE - 23 are mandatory fields.
7.1.2.2 e-Commerce Purchase Transaction
• For an e-Commerce transaction, acquirer must populate appropriate e-Commerce indicator.
• DE 14 should be mandatory for an e-commerce transaction.
• For an E-commerce transaction DE 25 should be 59.
7.1.2.3 Balance Inquiry Transaction
• For Card present transactions, track 2 data must be present.
• For balance inquiry transactions, transaction amount (DE - 4) must contain value 0.
• For Card not present (CNP) transactions, DE - 14 is mandatory.
• For chip based transactions, DE - 55 (all mandatory tags) and DE - 23 are mandatory fields.
7.1.2.4 ATM Cash Withdrawal Transaction
• For Card present transactions, track 2 data must be present.
• For cash withdrawal transactions, transaction amount (DE - 4) must not contain value 0.
• For Card not present (CNP) transactions, DE - 14 is mandatory.
• For chip based transactions, DE - 55 (all mandatory tags) and DE - 23 are mandatory fields.
7.1.2.5 Reversal Transaction
NCHL receives transactions from the following sources:
- Acquirer Bank terminals
- Third party processor terminals
- Other Payment gateway
These transactions can seamlessly traverse the NCHL Member Bank Interface to reach the NCHL Issuer Bank Switch for secure authorization.
A Reversal can be generated for a number of reasons:
- Failure at the terminal side due to following reasons, acquirer is liable to generate the reveral message and forward it to NCHL.
a. Device exception b. Message corruption c. Communications failure
- Cancellation or a void due to following reasons, acquirer is liable to generate the reveral message and forward it to NCHL.
a. Customer cancellation b. Retailer cancellation
- Timeout of the Response or late response at the Acquirer or NCHL, in this case Acquirer or NCHL either is liable to generate reversal message.
Note:Acquirer to ensure not to support partial reversal from ATM and should not generate and send the partial/suspect reversal to NCHL. If sent NCHL to decline with format error and this would result in manual reconciliation.
Reversal message compliances:
• For a reversal transaction acquirer should not populate DE - 14, DE - 35, DE - 52, and DE - 45.
• A reversal transaction should always be sent as an advice.
• A reversal must be generated within next 1 cut-over from the date of transaction with the original transaction detail like RRN, date, time, amount, PAN, currency code. Each cut-over cycle is of 24 hours.
• Acquirer should send STAN & RRN of original transaction in reversal messages.
• Acquirer shall not forward the partial reversal to NCHL.
7.1.2.6 Authorization Advice Transaction
• For an authorization advice transaction, acquirer should not populate DE - 14, DE - 35, DE - 52, and DE - 45.
7.1.3 Standards related to Compliance
• All messages should comply with ISO 8583:1987 standards with the deviation mentioned as per NCHL NPS Card Switching Interface Specification.
• PIN accepted on the terminal must be encrypted with TDES.
7.2 Issuer Compliance
The following section describes various compliances required for issuers.
7.2.1 General Compliances
• Message sent to NCHL must be structured as per this specification document. • Issuer need to verify all authentication related data like PIN, OTP, CVV1, CVV2, etc. • Issuer need to respond the request within the defined time out period, otherwise NCHL will generate reversal towards issuer and declined transaction towards acquirer. • Issuer need to populate all the data elements in the response as per the message specification. • All advice messages need to be acknowledged. • Customer and device sensitive data like PIN, expiry date, track, POS condition code, POS Entry Mode must not be echoed back in the response. • Acquirer/ NCHL may generate reversal for next 24 hours. SAF retry counts will be configured as needed. • For all successful transactions Issuer needs to populate DE 38.
7.2.2 Transaction Compliances
Various transactions have different compliance requirements as mentioned hereafter.
7.2.2.1 Purchase Transaction
• Issuer shall populate response code (DE – 39) for all transactions.
• Issuer need to populate authorization code (DE – 38) for all approved transactions (DE 39 = 00).
• For purchase with cash back transactions, transaction amount should be present in DE - 4 and cash back amount should be present in DE - 54. The value of DE - 54 should be less than DE - 4.
• For all purchase transactions, DE - 14, DE - 23, DE – 35, DE – 45, DE – 52 should not be sent in the response.
7.2.2.2 e-Commerce Purchase Transaction
• Issuer shall populate response code (DE – 39) for all transactions.
• Issuer need to populate authorization code (DE – 38) for all approved transactions (DE 39 = 00).
• For all e-Commerce purchase transactions, DE - 14, DE - 23, DE – 35, DE – 45, DE – 52 should not be sent in the response.
7.2.2.3 Balance Inquiry Transaction
• Issuer shall populate response code (DE – 39) for all transactions. • Issuer need to populate authorization code (DE – 38) for all approved transactions (DE 39 = 00). • Issuer need to populate balances in DE – 54. • For all balance inquiry transactions, DE - 14, DE - 23, DE – 35, DE – 45, DE – 52 should not be sent in the response.
7.2.2.4 ATM Cash Withdrawal Transaction
• Issuer shall populate response code (DE – 39) for all transactions.
• Issuer need to populate authorization code (DE – 38) for all approved transactions (DE 39 = 00).
• For all ATM cash withdrawal transactions, DE - 14, DE - 23, DE – 35, DE – 45, DE – 52 should not be sent in the response.
7.2.2.5 Reversal Transaction
This message advices to reverse the activity of a previous authorization. It notifies NCHL Host and/or the issuer of an error condition regarding an earlier financial transaction/ balance update transaction if: • An approved transaction is cancelled at the POS or ATM device. • Acquirer does not receive a response to a financial request request. • Acquirer cannot send an approved response to the POS or ATM device.
When issuer receives any kind of reversal messages from NCHL (generated by Acquirer or NCHL), isuuer shall confirm the legitimity of that message and then shall process this reversal transaction.
Reversal message compliances:
• Issuer shall populate response code (DE – 39) for all transactions. • Issuer need to populate authorization code (DE – 38) for all approved transactions (DE 39 = 00). • For all reversal transactions, DE - 14, DE – 23 should not be sent in the response.
7.2.2.6 Authorization Advice Transaction
• Issuer shall populate response code (DE – 39) for all transactions. • Issuer need to populate authorization code (DE – 38) for all approved transactions (DE 39 = 00). • For all authorization advice transactions, DE - 14, DE - 23, DE – 52 should not be sent in the response.
7.2.3 Standards related to Compliance
• All messages should comply with ISO 8583:1987 standards with the deviation mentioned as per NCHL NPS Card Switching Interface Specification.
7.3 Industry Compliance
7.3.1 Payment Card Industry Compliance
Payment card industry compliance (PCI) refers to the technical and operational standards to secure and protect card data provided by cardholders and transmitted through card processing transactions. PCI standards for compliance are developed and managed by the PCI Security Standards Council. Payment Card Industry Data Security Standard (PCI DSS) is an information security standard that applies to all entities involved in processing, storing, and/or transmitting payment card information.
• Any terminal/ merchant that accepts card payments must comply with PCI mandates.
• Failure to achieve and maintain PCI compliance can leave a terminal/ merchant vulnerable to a data breach and the ensuing negative fallout including fines, fees, and lost business.
• NCHL issuer and acquirer member who issues/ accepts/ processes cardholder data shall certify the latest available version of PCI DSS.
7.3.2 ISO 27001 Compliance
ISO framework is a combination of policies and processes for organizations to use. ISO 27001 is an international standard which provides framework that helps organizations manage the security of their information assets. It provides a management framework for implementing an Information Security Management System (ISMS) to ensure the Confidentiality, Integrity, and Availability (CIA) of all corporate data (such as financial information, intellectual property, employee details or information managed by third parties). NCHL members can have better appendage security measures if they are certified for ISO 27001.