Fall Mandate Notification – August 31, 2016 Updated September 22, 2016 **Highlighted updates are provided for clarification and to provide additional information**

2016 Fall Mandate Notification CO-OP Financial Services will implement the code changes required to support card association and EFT network Fall Mandates on Friday, October 14, 2016, unless otherwise noted. CO-OP has identified requirements that may impact your host processor. The requirements in support of these mandates are detailed in this update. While CO-OP forwards copies of our Hardware/Software Compliance Updates to our known software vendor contacts, it is up to each credit union to check with their software vendor to ensure their vendor has the information needed to support these changes. If a 3rd party authorizes transactions on your behalf, often referred to as a service bureau, you should forward this information to them. Please note: DataNavigator will be taken offline at 7 p.m. PT on October 14, 2016, to install the code changes required to support the mandates. DataNavigator will be unavailable for approximately two hours. Questions regarding your credit union network participation should be verified with the sponsorship or contracts administrator within your organization. Some credit unions have issued a Debit MasterCard with Plus sponsorship or a Visa Debit card with Cirrus sponsorship. In these cases, both the MasterCard and Visa changes would apply. The changes dictated by the card associations and EFT Networks are required to remain in compliance with each of the networks. The dates for compliance have been set by each card association or network. Please contact Client Services at 800.782.9042, option 2, with any questions.

1 of 14

Summary by Association/Network Note: All services are required unless otherwise noted. MasterCard MasterCard Automatic Billing Updater Credit and Debit – pg. 3 Downgrading MasterCard SecureCode Transactions Credit, Debit and Maestro – pg. 3 Visa Visa Account Updater Debit and Credit – pg. 3-4 Alignment of Merchant Initiated Transactions PAVD, Interlink, Debit and Credit – pg. 4-5 Changes to Eliminate Referral Responses from Issuers PAVD, Interlink, Debit and Credit – pg. 5 New Payment Reference Number Field in Visa Token Service Messages PAVD, Interlink, Debit and Credit – pg. 5 CO-OP CO-OP VAU/ABU Support – pgs. 5-7 STAR STAR Access – pgs. 7-10 DE111 – Additional Data, Private Acquirer, “ST” Tag Layout – pgs. 11-12 DE127 - Acquirer Trace Data, Visa Format Layout – pgs. 13-14

2

MasterCard MasterCard Automatic Billing Updater (Credit and Debit) Effective April 21, 2017, MasterCard is requiring participation in the Automatic Billing Updater (ABU) program. ABU is a program that will seamlessly update account–on-file information and help prevent disruptions due to account changes. MasterCard is looking to extend the life of online and offline account-on-file and automatic recurring payment arrangements by helping to secure these ongoing, revenue-generating relationships by maintaining service continuity and cardholder satisfaction. Using ABU can reduce the number of declined authorization requests and lost sales opportunities for account-on-file payments. The ABU program accepts account change data from issuers, which MasterCard stores on behalf of their registered merchants. Effective July 2016, MasterCard expanded the ABU issuer database to a rolling 50 months. By maintaining a database of 50 months, allowing acquirers, on behalf of their registered merchants, the ability to validate accounts for their full life cycle. CO-OP has a waiver in place to install the processor requirements to support ABU by November 30, 2016. However, we recognize that in order to facilitate these requirements, all core vendors will be required to make code changes. On your behalf, CO-OP submitted a request to MasterCard asking that card issuers be given until October 2017 to complete the code changes required to provide the necessary card information to CO-OP so it can be included in the file sent to MasterCard. MasterCard has granted this waiver request. See CO-OP VAU/ABU section for further details. Downgrading MasterCard SecureCode Transactions (Debit, Credit and Maestro) Merchants that participate in MasterCard SecureCode are required to attempt to authenticate a cardholder before submitting a transaction for authorization. MasterCard will be introducing an edit that will downgrade a MasterCard SecureCode transaction to a non-SecureCode transaction when the acquirer is unable to clearly demonstrate they actually authenticated or attempted to authenticate the cardholder. When the transaction is downgraded by MasterCard there will be no SecureCode information sent to the issuer.

VISA Visa Account Updater (Credit and Debit) Effective with the Fall Mandates, Visa is requiring participation in the Visa Account Updater (VAU) service. VAU is a service that will enable the secure exchange of updated account information among participating issuers, acquirers, and qualified account-on-file merchants to address the requirements of recurring payments and periodic transactions. In addition, VAU supports typical account renewal or card replacement; account upgrades or downgrades; portfolio acquisitions and/or mergers; lost/stolen cards; other account closures; and MasterCard-to-Visa, American Express-to-Visa, Discover-to-Visa, and Visa-to-Visa conversions. 3

VAU provides the means for issuers to communicate the most current changes to cardholder account information to participating merchants in support of card-on-file functions. Providing a means for merchants to update the card-on-file information ensures recurring payments and subscription services will continue without negative impact to your members. VAU is designed to provide an automated secure means to make timely changes to cardholder account information. CO-OP has a waiver in place to install the processor requirements to support VAU by November 30, 2016. However, we recognize that in order to facilitate these requirements, all core vendors will be required to make code changes. On your behalf, CO-OP submitted a request to Visa asking that card issuers be given until October 2017 to complete the code changes required to provide the necessary card information to CO-OP so it can be included in the file sent to Visa. Visa has granted this waiver request. See CO-OP VAU/ABU section for further details. Alignment of Merchant Initiated Transactions (PAVD, Interlink, Credit and Debit) Visa is introducing new authorization processing requirements for merchant initiated transactions and authorization enhancements to enable greater visibility to the type and nature of transactions that support PAN and token processing. Visa rules currently require most merchants to seek an authorization only when the final transaction amount is known. Exceptions exist in a number of merchant segments and Visa rules allow hotel, car rental and cruise line merchants to obtain an estimated authorization at the time of check-in/rental and to request incremental authorizations if needed. Visa is expanding the range of merchant that may request an estimated or initial authorization if the final amount is not known when the transaction is initiated, as well as any subsequent incremental authorization. Trailer parks, campgrounds and merchants that offer rentals such as aircraft, bicyle, boat, motor home and motorcycle rentals bay use both estimated and incremental authorizations. Transit and Transportation MCC’s 4111, 4112 and 4131 may continue to perform an initial authorization request (i.e., an authorization for the lowest available fare) and incremental authorization request up to $25 internationally or $15 domestically. Amusement Parks, Circuses, Carnivals and Fortune Tellers using MCC 7996 may perform estimated and incremental authorization. Restaurants and Eating Places, MCC 5812 and Drinking Places, MCC 5813, may perform initial and incremental authorizations. The authorizations must not be estimates, and they must reflect the value of goods actually ordered by the cardholder. The advice messages 0120 and 0220 for these authorization types will have the Advice Reason Code 24 (acquirer originated advice/within business agreement) in DE060. A new field, Original Transaction Identifier, will be added to DE127, Format Code 4, and will be populated with the PS2000 Transaction Identifier (existing field in DE127, Format Code 4) from the 4

original transactions or the previous authorization in a series of merchant initiated transactions. The updated DE127 layout is below. A new value of “C” (Credentials on File) is being added to DE111, VD tag, Recurring Payment Indicator field, to identify transactions where the cardholder credentials are being placed on the file for the first time. This new value will be sent when the merchant is initiating the first transaction in a series on behalf of the cardholder using credentials stored on file. The new value will be supported in 0100, 0120, 0200, 0220 and 0420 message types. You will begin to see a value of “81” (From File) in positions 1-2 of DE022 when the merchant is initiating a transaction on behalf of the cardholder using credentials stored on file. The POS Entry Mode of “81” is supported in 0100, 0120, 0200, 0220 and 0420 message types. Changes to Eliminate Referral Responses from Issuers (PAVD, Interlink, Credit and Debit) Visa is implementing new processing rules and will no longer accept response codes of “01” (refer to card issuer) or “02” (refer to card issuer, special condition). Visa will reject any 0110 or 0210 response with those response codes. Hosts should no longer send response codes “01” or “02”. If received from a host CO-OP will map to a “05” (do not honor) out to Visa. New Payment Reference Number Field in Visa Token Service Messages (PAVD, Interlink, Credit and Debit) Visa is implementing a new field, Payment Account Reference, to support the Visa Token Service. The Payment Account Reference value will be assigned by Visa and can be used to link transactions initiated with payment tokens to the original card number. This new Payment Account Reference will allow merchants who only know the token PAN to have a reference to apply loyalty rewards to a single cardholder, since in some cases multiple token PANs can be associated with a single original card number. CO-OP will be passing the Payment Reference Number data in DE124 under a new tag, “PR”. The format will be “PRnnxxxxxxxxxxxxxxxx”, where “n” is the length and “x” is the data. The Payment Reference Number can be present in token provisioning, token life cycle and purchase transactions.

CO-OP CO-OP VAU/ABU Support To assist vendors in their coding efforts, the overall implementation approach is the same for both Visa Account Updater and MasterCard ABU. The batch maintenance file changes required will support both association requirements. VAU/ABU will be supported in both the APBATCH2 and APBATCH4 file specifications. The new file specifications will be published shortly as we are awaiting confirmation from the networks on a few last minute details. In addition, Cardholder Maintenance fields will be updated to include the new information where applicable. Credit unions have choices on how to handle the VAU/ABU requirements. In determining what option will work best for your credit union, your current processing options at CO-OP will come into play. 5

Processing options are as follows: 1) CO-OP creates the file for credit unions that use the Authorization Processor services, e.g. AP Authorization with Balances or AP Cooperative. Note: We will support creating the VAU/ABU files for clients that are using a cardholder file for the fraud demographic reporting only (AP Lite). For clarification, some clients that use AP Authorization with Balances do not do batch maintenance. They enter all their card and account information into the CO-OP Cardholder Maintenance application directly. Cardholder Maintenance screens will be updated to support the data required by MasterCard and Visa and the credit union will be responsible for maintaining them. CO-OP will create a file to MasterCard and/or Visa with the information updated by the credit union. a. Credit unions will need to modify their Batch Maintenance files to include data required for VAU/ABU updates. CO-OP will generate a daily VAU/ABU file and forward to the networks. b. Reports from the network will be included in credit union daily distribution. 2) Credit union creates the file in the network format and use CO-OP as a Pass Through-Only processor for VAU/ABU. a. These clients will generate and send the daily file to CO-OP, according to the VAU/ABU specification and we will pass them through to Visa/MC. b. CO-OP will distribute the VAU/ABU reports to its clients. c. This option will require the credit union to include an identifier, unique to Visa/MC, in the VAU/ABU detail records. Visa has specified a new value called the Segment ID and MC will make use of the existing ICA (Interbank Card Association) value. This value will also be used to identify the credit union for report distribution. CO-OP will need to coordinate this value with the client to ensure the VAU/ABU reports can be correctly distributed. 3) Credit union creates and sends the VAU/ABU files in the network format and send directly to the network. You will receive reports directly from the network. CO-OP has no involvement if you choose this option. Note: Credit union host processing clients that do not maintain card files at the switch will need to choose option #2 or #3. New Card Maintenance Field VAU-ABU Indicator New Expiration Date

Old PAN

Old Expiration Date

Description The issuer will use this value to indicate whether this update is for VAU or ABU. The issuer will provide the new expiration date, when the maintenance scenario requires it. Note: For issuers that order cards through CO-OP and are configured for auto reissues, the card order records will be used to provide this data and there is no need to supply this data. The issuer will provide the old PAN, when the maintenance scenario requires it. Credit unions that use the cardholder file for the fraud demographic reporting only will need to provide this data. The issuer will provide the old expiration date, when the maintenance scenario requires it. Credit unions that use the cardholder file for the fraud demographic reporting only will need to provide this data. Note: For issuers that order cards through CO-OP and are configured for auto reissues, the card order records will be used to provide this data and there is no need to supply this data.

6

Reason Code

Reverse Code

Conversion Code

The issuer will use this value to indicate the VAU or ABU reason for the update. CO-OP requires that this value be a valid VAU or ABU value, depending on whether it is a VAU or ABU update. It is expected that the credit union become familiar with the valid VAU/ABU values, and under what circumstances they should be used, according to the network specifications. Visa has identified a separate field to indicate that a recent issuer submission was sent in error. CO-OP will support this scenario, if the issuer chooses to use it, by adding this field to the cardholder maintenance methods. Visa has identified a separate field to indicate a portfolio conversion. CO-OP will support this scenario, if the issuer chooses to use it, by adding this field to the cardholder maintenance methods. Note: MC has similar support, but makes use of the Reason Code to indicate portfolio conversion.

Both Visa and MasterCard will be providing reporting around VAU and ABU. Reporting information will be provided along with the batch maintenance file changes within the next few weeks. Additional information on VAU/ABU will be published Friday, September 30. Information will include the new specification for APBATCH2 and APBATCH4. In addition, information downloaded from both Visa and MasterCard concerning their specifications and best practices as well as report samples will be included.

STAR STAR Access In April 2015, the STAR Network launched the first phase of STAR Access. STAR Access is designed to provide convenience and choice for STAR Members and cardholders by expanding support for all debit transactions through all payment channels using all payment devices. The first phase limited functionality to select card-present transactions processing the current Single Message Specification (SMS) environment for purchases, merchandise returns, pre-authorizations and preauthorization completion. As published in our Spring Mandate document, STAR has now announced the full launch of STAR Access to expand the authentication options and processing environments available. This phase will expand the STAR Access footprint into a greater segment of eligible transactions by enhancing the existing SMS environment and message format, as well as introducing a new dual message specification interface and supporting processes. STAR is requiring each STAR Issuer with cards that are capable of performing POS or Internet transactions to participate in STAR Access.

7

The STAR Access implementation date has yet to be determined, however, we wanted to provide the technical specifications and the information needed for credit union hosts to support the new and enhanced STAR Access transactions once they are enabled. STAR Access will provide support for Automated Fuel Dispense (AFD) authorization request messages for both Single Message System (SMS) and Dual Message System (DMS) acquirers. Transactions will be identified with MCC 5542, Petroleum Unattended. For SMS acquirers the transaction is initiated with a 0100 pre-authorization request. The request has a life cycle of 2 hours which will be sent in DE057. The transaction can be fully approved or partially approved by the issuer. Support of partial authorizations is required for issuers. Once the cardholder pumps their fuel, the acquirer will send a 0220 completion message with the final purchase amount. For DMS acquirers the transaction is initiated with a 0100 authorization message for $1.00. The request will not contain a life cycle indicator in DE057. The $1.00 represents an authorization of up to $100 if the transaction is fully approved or it could be partially approved by the issuer. Once the cardholder pumps their fuel, the acquirer will send a 0120 completion advice for the full amount of the purchase. This will provide the actual amount that should be held. At a merchant determined time, the acquirer will send a 0220 completion message that will match the amount from the 0120. Typically the completion message should be received the next day. STAR Access will support Balance Inquires initiated from a POS terminals for either SMS or DMS acquirers. The Balance Inquires will be 0200 messages with process code 31xx00. Recurring payment transactions are supported and can be identified by the value of “4” in DE058 position 4. Partial authorizations are not permitted on recurring payments. Account Verification transactions are supported and will be sent as 0200 with a process code of 33xx00. These transactions are to verify the validity of a card and may contain AVS and CVV2/CVC2 data. AVS data will be sent in DE123 and standard AVS response codes should be returned. 33xx00 is a new process code for STAR Account Verification. Most other networks use a purchase process code of 00xx00. Please be sure to add process code 33xx00 to your transaction tables. Valid AVS Results are: • • • • • • • • •

A = Address matches, zip code does not. N = Nothing matches. R = Retry, system unable to process. S = AVS not supported U = No data from issuer/Banknet Switch. W = 9-digit zip code matches, but address does not. X = Address and 9-digit zip code match exactly Y = Address and 5-digit zip code match. Z = 5-digit zip code matches, but address does not

Transit and eCommerce merchants are allowed to originate aggregated transactions. eCommerce transactions must be electronically authorized and settled for the total amount. Transit merchants designated as commuter transit may aggregate small transactions in a face-to-face environment. Transit merchants with the below MCCs are eligible:

8

• • • •

4111 – Local and Suburban Commuter Passenger Transportation, including Ferries and Railways. 4112 – Passenger Railways 4131 – Bus Lines 4784 – Bridge and Road Fees/Tolls

The permitted Aggregation Period and Aggregation Amount for eCommerce is 3 calendar days and $25, and for Transit merchants, 7 calendar days and $25 dollars. The Aggregation Amount may be less if approved with a partial authorization. To identify aggregated transactions we will be adding a Transaction Aggregation Indicator in a new “ST” tag in DE111 (see layout below), and a new tag of AGGR in DE104. The format of AGGR tag in DE104 is: AGGR; The AGGR tag will appear as “AGGRbY” or “AGGRbN”, where AGGR = Aggregation Tag b = blank Y/N = Merchant Aggregation Indicator Bill Payments will be supported for SMS and DMS acquirers. SMS acquirers will send a 0200 message with process code 50xx00. DMS acquirers will send a 0100 authorization and 0220 completion with process code 50xx00. STAR Access will provide support of Incremental Authorizations. Incremental Authorizations will contain the following data from the original authorization transaction to facilitate matching. • • • •

System Trace Audit Number – DE011 Incremental Authorization Indicator – DE111, “ST” tag Transaction Identifier (ATSN) - DE111, “ST” tag Acquirer Reference Number (ARN) - DE111, “ST” tag

According to the STAR documentation, the Transaction Identifier (ATSN) may have a relationship to DE037-Retrieval Reference number and will be created by STAR during the authorization request. We will provide more information as it becomes available. Travel Service merchants are permitted to have multiple authorizations and the authorization to transaction amounts are allowed up to a 15% variance. Partial Authorizations are permitted on STAR Access transactions. Issuers should use current partial authorization processing to partially approve a STAR Access transaction. If you have converted to CO-OP’s New Partial Authorization Methodology you will receive the partial authorization eligibility indicator in DE063. STAR Access will allow Multiple Clearing (split shipment) transactions for Airline and card not present/cardholder not present transactions as indicated in DE058. This will allow merchants to process multiple shipments from a single order and send a clearing message after each item is shipped. The first clearing transactions will contain Multi-Clear Sequence Number in DE124, “SN” tag and Multi-Clear Count Number DE124, “CN” tag. The Multi-Clear Sequence Number is used to show which clearing transaction out of total expected messages. The Count Number is the total expected 9

clearing transactions. The value in the Sequence Number should never be higher than the Count Number. For example, the if two clearing transactions will be sent, the first will have a Sequence Number of “1” and Count Number of “2” and the second (final) will have a Sequence number of “2” and a Count Number of “2”. All clearing transactions must be processed within seven days from the original authorization date. STAR Access will support gratuity based transactions from restaurants, taxi cabs, bars/taverns, beauty and barber shops, and health and beauty spas. A tip variance of 20% will be supported between the pre-authorization and completion. STAR requires DE038, Authorization ID, to be populated by issuers for STAR Access 0110 and 0210 authorization approvals with response codes of “00” (approval) and “10” (partial approval). If the issuer returns a 0110 or 0210 authorization without DE038 populated, STAR will reverse the 0110/0210 response back to the issuer. Quasi-Cash transactions will also be allowed with STAR Access. They will be 0200 messages with a process code of 00xx00. Quasi-Cash transaction will have a “Q” in the Market Indicator field of DE111, ST tag. STAR will forward the interchange fees in the online message for STAR Access transactions. Interchange fees will not be settled with a transactions. They will be sent in DE046. They will have a Fee Type of “00” – Transaction Fee and Settle/Memo Indicator of “0” –Memo/non-settled. The following POS Entry Mode values can be sent in DE022 for STAR Access transactions. • • • • • • • • •

00 01 02 05 07 79 80 90 91

– – – – – – – – –

Unspecified Manual Mag Stripe (partial) Contact Chip Contactless Chip Chip Card or Chip-capable Chip Card or Chip-capable Mag Stripe (full) Contactless Chip

STAR Access transactions will have a Network ID of “AXS” in DE063.

10

111 ADDITIONAL DATA, PRIVATE ACQUIRER Format:

LLLVAR

Attributes:

FIS: ans..255 ISO: ans..999

Description:

This data element is reserved by ISO for private definition and use. FISdefines this data element as Additional Data, Private Acquirer, which contains additional information for Visa® DCS, Visa EVES, Visa DCS CRISSM, Benefits Transfer, MasterCard® CIS, MasterCard IPM and PLUS® format. The layouts for this data follow.

STAR Format Sub-element Name/Contents Data Identifier. Value: ST Data Length (byte map + variable data) Data Byte Map Variable Data (Based on Byte Map) Payment Initiation types

Length

FINIPC bit

2

N/A

3 8

Additional Notes

N/A NA

2

1

Values: 00 = Card 01 = Mobile phone 02 = Fob 03 = Watch 04 = Mobile tag 05 = Wristband 06 = Mobile case 07-99 = Future Use Cardholder Identification Method

1

2

Values: 1 No CIM 2 Reserved for Future Use 3 Signature STAR Verification Value Market Indicator

10 1

3 4

Values: B - Bill pay G - Goods & services H - Healthcare L - Prepaid load M - Money transfer Q - Quasi cash 11

STAR Assigned value

Merchant Aggregation Indicator Values: Y - Yes, processed by Merchant Facilitator N or space - No Transaction Aggregation Indicator

1

5

1

6

Transaction Description

2

7

Values: AA - Account-to-Account PP - Person-to-Person BB - Business-to-Business BP - Business-to-Person OG - Online Gambling (Winnings) - For Future Use ATSN

15

8

1

9

23

10

3

11

15

12

Values: N or space = Not Aggregated E = e-commerce T = Transit

Incremental Authorization Indicator Values: Space = Not an incremental authorization I = Incremental authorization DE110, Acquirer Reference Number Position 1: ‘8’ = Sale ‘9’ = Refund Positions 2-7: Acquirer ID (BIN) Positions 8-11: Julian Date Positions 12-22: Acquirer Use – (own internal information) Position 23: Check Digit Interchange Program Identifier Passenger Transport Ticket Number

12

Unique ID assigned by the STAR Network at time of authorization response. ATSN is a lifecycle indicator. The last digit of the 15-byte data element will represent when STAR has assigned it.

Represents the ticket or invoice number for the airline or railway Carrier

127 ACQUIRER TRACE DATA Format:

LLLVAR

Attributes:

FIS: ans..100 ISO: ans..999

Description:

This data element is reserved by ISO for private definition and use. FISdefines this data element as Acquirer Trace Data. It is used to send the acquirer’s trace data, stored in the FINIPC field acquirertrace-ID. This allows information that is stored by the PI communicating to the acquirer to be sent to the issuer.

Visa® Format

NOTE:

For additional information and values for the Visa fields referenced below, see the V.I.P. System SMS Interlink Technical Specifications.

Length

Format Code. Value: 4

1

System Trace Audit Number

6

11

Acquirer's Institution Identification Code

11

32

Retrieval Reference Number

12

37

Authorization Characteristics Indicator

1

62.1

PS2000 Transaction Identifier

15

62.2

Multiple Clearing Sequence Number

2

May be blank

62.11

Multiple Clearing Sequence Count

2

May be blank

62.12

Merchant Volume Indicator

2

May be blank

63.18

Special Condition Indicator

1

May be blank

60.4

13

Notes

Visa Field No.

Subelement Name

POS Entry Mode

4

22

Point of Service Condition Code

2

25

Terminal Entry Capability

1

Chargeback Reduction/Base II flags

7

63.6

Acquirer Business/Member ID

8

63.8

Fee Program Indicator

3

63.19

Market Indicator

1

62.4

Response Source/Reason Code

1

44.1

Original Transaction Identifier

15

125.3

May be blank

14

60.2