shazam, inc....shazam, inc.’s controls throughout the period january 1, 2017, to october 31, 2017....

System and Organization Controls Report

Report on Controls Placed in Operation and Tests of Operating Effectiveness

For the Period January 1, 2017, to October 31, 2017

SHAZAM, Inc.

Electronic Funds Transfer System

SHAZAM, INC. TABLE OF CONTENTS

I. Independent Service Auditor’s Report ........................................... 1

II. SHAZAM, Inc.’s Assertion ............................................................... 4

III. SHAZAM, Inc.’s Description of its Electronic Funds Transfer System .............................................................................................. 6

Overview of Operations.................................................................................................................... 6

Company Profile ........................................................................................................................ 6

Overview of Services Provided.................................................................................................. 6

Scope of Report ....................................................................................................................... 13

SHAZAM, Inc. EFT System and Components ............................................................................... 13

Relevant Aspects of the Control Environment, Risk Assessment Process, Information and Communication Systems and Monitoring Controls ........................................................................ 14

Control Environment ................................................................................................................ 14

Risk Assessment Process ....................................................................................................... 18

Information and Communication Systems ............................................................................... 18

Monitoring Controls ................................................................................................................. 19

Information Technology General Computer Controls .................................................................... 19

Information Security ................................................................................................................. 19

Systems Development and Change Management .................................................................. 23

Computer Operations .............................................................................................................. 26

NOC ......................................................................................................................................... 28

Application and Business Process Controls .................................................................................. 29

Switch Processing ................................................................................................................... 30

Merchant Transaction Processing ........................................................................................... 33

DPC Stand-In Authorization .................................................................................................... 34

Card Authorization Services .................................................................................................... 36

ACH Receive ........................................................................................................................... 37

ACH Origination ....................................................................................................................... 37

PIN Processing ........................................................................................................................ 38

Key Management .................................................................................................................... 39

Settlement ................................................................................................................................ 40

Switch Usage Billing ................................................................................................................ 40

Chargebacks and Disputed Items ........................................................................................... 41

Fraud Operations ..................................................................................................................... 42

Report Generation and Distribution ......................................................................................... 44

Key Reports ................................................................................................................................... 44

Information Used in the Execution of a Control ....................................................................... 44

Information Prepared for User Entities .................................................................................... 46

Complementary Subservice Organization Controls ....................................................................... 46

Complementary User Entity Controls ............................................................................................. 47

IV. SHAZAM, Inc.’s Control Objectives and Related Controls and RSM US LLP’s Tests of Controls and Results of Tests .............. 49

Organization and Administration Controls ..................................................................................... 49

Computer Operations Controls ...................................................................................................... 52

SHAZAM, INC. TABLE OF CONTENTS

Physical Access Controls ............................................................................................................... 55

Logical Access Controls ................................................................................................................. 57

System Development and Maintenance Controls .......................................................................... 61

Application and Business Process Controls .................................................................................. 64

V. Other Information Provided by SHAZAM, Inc. ............................. 77

Due Diligence Information .............................................................................................................. 77

Information Security and Privacy ................................................................................................... 78

SHAZAM Initiatives and Product Changes .................................................................................... 79

Payment Card Industry Data Security Standard ............................................................................ 80

Annual Assessment ................................................................................................................. 80

Quarterly Scan Results ............................................................................................................ 80

Business Continuity ........................................................................................................................ 80

Operating Environment Resiliency .......................................................................................... 81

Computer Operations Monitoring Initiatives ............................................................................ 81

Other PIN Processing and Key Management Information ............................................................. 81

PIN Processing ........................................................................................................................ 81

Key Management .................................................................................................................... 82

I. Independent Service Auditor’s Report

To Management of SHAZAM, Inc.

Scope

We have examined SHAZAM, Inc.’s description of its electronic funds transfer system entitled “SHAZAM, Inc.’s Description of its Electronic Funds Transfer System” for processing user entities’ transactions throughout the period January 1, 2017, to October 31, 2017, (the “description”) and the suitability of the design and operating effectiveness of controls included in the description to achieve the related control objectives stated in the description, based on the criteria identified in “SHAZAM, Inc.’s Assertion” (the “assertion”). The controls and control objectives included in the description are those that management of SHAZAM, Inc. believes are likely to be relevant to user entities’ internal control over financial reporting, and the description does not include those aspects of the system that are not likely to be relevant to user entities’ internal control over financial reporting.

The information included in Section V, “Other Information Provided by SHAZAM, Inc.,” is presented by management of SHAZAM, Inc. to provide additional information and is not a part of SHAZAM, Inc.’s description of its electronic funds transfer system made available to user entities during the period January 1, 2017, to October 31, 2017. Information about SHAZAM, Inc.’s due diligence, product enhancements, information security, privacy, Payment Card Industry (PCI) compliance, key management and business continuity practices in Section V has not been subjected to the procedures applied in the examination of the description of the electronic funds system and of the suitability of the design and operating effectiveness of controls to achieve the related control objectives stated in the description of the electronic funds transfer system, and accordingly we express no opinion on it.

SHAZAM, Inc. uses a subservice organization for authorizations, settlement, reporting, billing and statements for merchant transaction processing. The description includes only the control objectives and related controls of SHAZAM, Inc., and excludes the control objectives and related controls of the subservice organization. Our examination did not extend to controls of the subservice organization, and we have not evaluated the suitably of the design or operating effectiveness of such complementary subservice organization controls.

The description indicates that certain control objectives specified in the description can be achieved only if complementary user entity controls assumed in the design of SHAZAM, Inc.’s controls are suitably designed and operating effectively, along with related controls at the service organization. Our examination did not extend to such complementary user entity controls, and we have not evaluated the suitability of the design or operating effectiveness of such complementary user entity controls.

Service Organization’s Responsibilities

In Section II of this report, SHAZAM, Inc. has provided an assertion about the fairness of the presentation of the description and suitability of the design and operating effectiveness of the controls to achieve the related control objectives stated in the description. SHAZAM, Inc. is responsible for preparing the description and assertion, including the completeness, accuracy and method of presentation of the description and the assertion, providing the services covered by the description, specifying the control objectives and stating them in the description, identifying the risks that threaten the achievement of the control objectives, selecting the criteria stated in the assertion, and designing, implementing and documenting controls that are suitably designed and operating effectively to achieve the related control objectives stated in the description.

Service Auditor’s Responsibilities

Our responsibility is to express an opinion on the fairness of the presentation of the description and on the suitability of the design and operating effectiveness of the controls to achieve the related control objectives stated in the description, based on our examination.

Our examination was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants. Those standards require that we plan and perform the examination to obtain reasonable assurance about whether, in all material respects, based on the criteria in management’s assertion, the description is fairly presented and the controls were suitably designed and operating effectively to achieve the related control objectives stated in the description throughout the period January 1, 2017, to October 31, 2017. We believe that the evidence we obtained is sufficient and appropriate to provide a reasonable basis for our opinion.

An examination of a description of a service organization’s system and the suitability of the design and operating effectiveness of the controls involves:

Performing procedures to obtain evidence about the fairness of the presentation of the description and the suitability of the design and operating effectiveness of those controls to achieve the related control objectives stated in the description, based on the criteria in management’s assertion

Assessing the risks that the description is not fairly presented and that the controls were not suitably designed or operating effectively to achieve the related control objectives stated in the description

Testing the operating effectiveness of those controls that management considers necessary to provide reasonable assurance that the related control objectives stated in the description were achieved

Evaluating the overall presentation of the description, suitability of the control objectives stated in the description, and suitability of the criteria specified by the service organization in its assertion

Inherent Limitations

The description is prepared to meet the common needs of a broad range of user entities and their auditors who audit and report on user entities’ financial statements and may not; therefore, include every aspect of the system that each individual user entity may consider important in its own particular environment. Because of their nature, controls at a service organization may not prevent, or detect and correct, all misstatements in processing or reporting transactions. Also, the projection to the future of any evaluation of the fairness of the presentation of the description, or conclusions about the suitability of the design or operating effectiveness of the controls to achieve the related control objectives, is subject to the risk that controls at a service organization may become ineffective.

Description of Tests of Controls

The specific controls tested and the nature, timing and results of those tests are listed in Section IV of this report.

Opinion

In our opinion, in all material respects, based on the criteria described in SHAZAM, Inc.’s assertion:

The description fairly presents the electronic funds transfer system that was designed and implemented throughout the period January 1, 2017, to October 31, 2017.

The controls related to the control objectives stated in the description were suitably designed to provide reasonable assurance that the control objectives would be achieved if the controls operated effectively throughout the period January 1, 2017, to October 31, 2017, and the subservice organization and user entities applied the complementary controls assumed in the design of SHAZAM, Inc.’s controls throughout the period January 1, 2017, to October 31, 2017.

The controls operate effectively to provide reasonable assurance that the control objectives stated in the description were achieved throughout the period January 1, 2017, to October 31, 2017, if complementary subservice organization and user entity controls assumed in the design of SHAZAM Inc.’s controls operated effectively throughout the period January 1, 2017, to October 31, 2017.

Restricted Use

This report, including the description of tests of controls and results thereof in Section IV of this report, is intended solely for the information and use of management of SHAZAM, Inc., user entities of SHAZAM, Inc.’s electronic funds transfer system during some or all of the period January 1, 2017, to October 31, 2017, and their auditors who audit and report on such user entities’ financial statements or internal control over financial reporting and have a sufficient understanding to consider it, along with other information, including information about controls implemented by user entities themselves, when assessing the risks of material misstatements of user entities’ financial statements. This report is not intended to be, and should not be, used by anyone other than these specified parties.

Des Moines, Iowa February 26, 2018

SHAZAM, INC. INFORMATION PROVIDED BY SHAZAM, INC.

Page 4

II. SHAZAM, Inc.’s Assertion

We have prepared the description of SHAZAM, Inc.’s electronic funds transfer system entitled “SHAZAM, Inc.’s Description of its Electronic Funds Transfer System” for processing user entities’ transactions throughout the period January 1, 2017, to October 31, 2017, (the description) for user entities of the system during some or all of the period January 1, 2017, to October 31, 2017, and their auditors who audit and report on such user entities’ financial statements or internal control over financial reporting and have a sufficient understanding to consider it, along with other information, including information about controls implemented by the subservice organization and user entities of the system themselves, when assessing the risks of material misstatements of user entities’ financial statements.

SHAZAM Inc. uses a subservice organization for authorizations, settlement, reporting, billing and statements for merchant transaction processing. The description includes only the control objectives and related controls of SHAZAM, Inc.’s electronic funds transfer system and excludes the control objectives and related controls of the subservice organization. The description also indicates that certain control objectives specified by SHAZAM Inc.’s can be achieved only if complementary subservice organization controls assumed in the design of SHAZAM’s controls are suitably designed and operating effectively, along with the related controls at SHAZAM Inc. The description does not extend to controls of the subservice organization.

The description indicates that certain control objectives specified in the description can be achieved only if complementary user entity controls assumed in the design of SHAZAM Inc.’s electronic funds transfer system controls are suitably designed and operating effectively, along with related controls at the service organization. The description does not extend to controls of the user entities.

We confirm, to the best of our knowledge and belief, that:

The description fairly presents the electronic funds transfer system made available to user entities of the system during some or all of the period January 1, 2017, to October 31, 2017, for processing their transactions as it relates to controls that are likely to be relevant to user entities’ internal control over financial reporting. The criteria we used in making this assertion were that the description:

- Presents how the system made available to user entities of the system was designed and implemented to process relevant transactions, including, if applicable:

The types of services provided, including, as appropriate, the classes of transactions processed

The procedures, within both automated and manual systems, by which services are provided, including, as appropriate, procedures by which transactions are initiated, authorized, recorded, processed, corrected as necessary and transferred to the reports presented to user entities of the system

The information used in the performance of procedures including, if applicable, related accounting records, whether electronic or manual, and, supporting information involved in initiating, authorizing, recording, processing and reporting transactions; this includes the correction of incorrect information and how information is transferred to the reports and other information presented for user entities

How the system captures and addresses significant events and conditions, other than transactions

The process used to prepare reports and other information for user entities

Services performed by a subservice organization, if any, including whether the carve-out method or inclusive method has been used in relation to them


Page 5

The specified control objectives and controls designed to achieve those objectives, including, as applicable, complementary user entity controls assumed in the design of the service organization’s controls

Other aspects of our control environment, risk assessment process, information and communications (including the related business processes), control activities and monitoring activities that are relevant to the services provided

- Includes relevant details of changes to the service organization’s system during the period covered by the description

- Does not omit or distort information relevant to the scope of the service organization’s system, while acknowledging that the description is prepared to meet the common needs of a broad range of user entities of the system and their user auditors, and may not, therefore, include every aspect of the electronic funds transfer system that each individual user entity of the system and its auditor may consider important in its own particular environment

The controls related to the control objectives stated in the description were suitably designed and operated effectively throughout the period January 1, 2017, to October 31, 2017, to achieve those control objectives if the subservice organization and user entities applied the complementary controls assumed in the design of SHAZAM Inc.’s controls throughout the period January 1, 2017, to October 31, 2017. The criteria we used in making this assertion were that:

- The risks that threaten the achievement of the control objectives stated in the description have been identified by management of the service organization.

- The controls identified in the description would, if operating as described, provide reasonable assurance that those risks would not prevent the control objectives stated in the description from being achieved.

- The controls were consistently applied as designed; including whether manual controls were applied by individuals who have the appropriate competence and authority.


Page 6

III. SHAZAM, Inc.’s Description of its Electronic Funds Transfer System

Overview of Operations

Company Profile

The SHAZAM Network, founded in 1976, is a national member-owned financial services and payments processing company. SHAZAM, Inc. (SHAZAM) provides choice and flexibility to community financial institutions throughout the United States. SHAZAM is a single-source provider of the following services: debit card, core system processing, fraud, ATM, merchant, marketing, training, risk and automated clearing house (ACH).

SHAZAM was founded on the principle that a shared electronic funds transfer (EFT) environment is beneficial for both financial institutions and their customers. For over 40 years, the SHAZAM Network has advocated equal access to the electronic payments system for institutions of various sizes.

Ownership Structure

SHAZAM is a not-for-profit corporation headquartered in Johnston, Iowa, and is solely composed of insured depository financial institutions. SHAZAM holds 100 percent of outstanding shares of ITS, Inc. SHAZAM, Inc. became the primary corporation in September 1994 when several subsidiaries and state organizations merged into the SHAZAM organization. Both corporations serve under the same governing board and are managed by the same officers.

SHAZAM is guided by a board of directors. The board consists of representatives from SHAZAM member financial institutions. Every member has the opportunity to vote or run for office, and elections are held each year. Membership is not a prerequisite to participate in the SHAZAM Network. SHAZAM’s ownership structure ensures that financial institutions of various types and sizes are represented.

ITS Bank became operational on January 1, 2000, and operates for the purpose of sponsoring SHAZAM participants into other networks. The federal regulators treat ITS Bank as a separate entity in their examinations.

SHAZAM is connected to international and national networks, allowing SHAZAM cardholders to have their transactions processed globally. More information about SHAZAM and its various products and services is available at www.shazam.net.

Overview of Services Provided

SHAZAM provides the following products and services to its financial institutions and merchants:

Authorization Services

SHAZAM provides options for card issuers to authorize financial transactions without being connected to the switch.

Card authorization files are provided by the issuer for SHAZAM to use when authorizing transactions based on daily limits.

Issuers periodically provide SHAZAM updated files containing cardholder balances.

Most of the software vendors have certified interfaces with SHAZAM to provide card and balance file information electronically.

http://www.shazam.net/


Page 7

Financial transactions authorized by SHAZAM on a financial institution’s behalf need to be posted to customer accounts. SHAZAM provides the transactions in a standard National Automated Clearing House Association (NACHA) formatted file. Banking systems import and post the transactions to customer accounts. The posting files are downloaded directly from SHAZAM through a secure internet connection, either manually with a web browser or automatically with a File Transfer Protocol (FTP) or network data mover (NDM) client. SHAZAM also provides the posting items through the Federal Reserve Bank (FRB) ACH network. Real-time financial authorization is addressed in the Switching Services section of this report.

ACH Services

The SHAZAM Network offers a variety of ACH services to financial institutions.

ACH association

The SHAZAM, Inc. ACH Association is one of the Regional Payments Associations (RPAs) of NACHA. As a member of the SHAZAM association, a financial institution becomes a member of NACHA. Member institutions include banks, credit unions, and savings and loans. There are also nonfinancial institutions as associate-level members.

ACH origination

SHAZAM offers SHAZAM ACH as its web-based ACH origination solution. SHAZAM ACH allows institutions to compete with much larger institutions offering ACH origination services to corporate clients.

SHAZAM ACH origination services allow the financial institution to offer a cash management service to corporate clients or use the system themselves.

ACH origination services also allow the ability to import non-ACH files (such as a fixed column text or .CSV file) into a database in the system to create NACHA files.

SHAZAM uses the Goldleaf warehousing application in support of SHAZAM ACH. This application pulls files from the directory and imports them into the data warehouse. The warehouse pulls batches with an effective date of the next business day or earlier to send to the Federal Reserve.

SHAZAM Access ACH origination is also available for financial institutions or their corporate originators. It allows the originator to transmit a NACHA-formatted file to SHAZAM using SHAZAM Access.

ACH receive

SHAZAM ACH receive provides a means for the electronic delivery of daily ACH files from the Federal Reserve via a high-speed bulk data connection to the FRB. SHAZAM offers the service to an institution regardless of its federal district or state.

Participating institutions have the following options:

- Pull the daily ACH file from SHAZAM via the same connection used to receive daily cardholder activity (for example: SHAZAM Access).

- Receive the files in a mainframe or server system

- Receive on behalf of multiple institutions.

The service allows the institution to use an alternative to FedLine or a correspondent institution. The files are provided in the morning to allow the institution to memo-post customer account balances for transactions with a settlement date. The multiple file/day receive option is also available.


Page 8

ATM Services

When participants use SHAZAM’s ATM services, the acquiring financial institution that owns the ATM contracts with SHAZAM to drive and monitor its ATMs. SHAZAM is capable of driving most leased-line and dial-up ATMs manufactured by ATM vendors. Financial institutions have the option to participate in a surcharge-free alliance within the SHAZAM Network called Privileged Status®.

SHAZAM’s ATM service supports the following types of transactions and features:

Deposits (both envelope and scanned)

Cash withdrawals, including dynamic currency conversion for qualifying transactions

Funds transfers between linked accounts

Balance inquiries

Multiple accounts for a single card

Surcharging

Privileged Status selective surcharge-free alliance

24/7 terminal status monitoring

Dedicated leased-line connections

Dial-up line and cellular connections

Support for customer supplied broadband connections

Merchandise dispensing

Electronic journal remote retrieval

Remote key load

Screen customization (in the welcome, wait and thank you states)

Voice guidance for Americans With Disabilities Act (ADA) compliance

File exchange with ATM

- Retrieve electronic journal

- Distribute campaign content

- Retrieve logs

- Update applications

- Apply operating system (OS) patches

SHAZAM ATMs are connected to SHAZAM through telecommunication lines. Transactions run to the SHAZAM switch and then to the card-issuing financial institution’s processor, other networks or SHAZAM’s Card Authorization Service (CAS) for authorization. Leased-line ATMs have a diagnostic modem supplied by SHAZAM. Dial-up ATMs use a different type of modem that is supplied or purchased from the ATM vendor.


Page 9

SHAZAM monitors ATMs using SHAZAM’s terminal monitoring service. This service automatically notifies the individual ATM’s first- or second-line servicing contact as specified by the acquiring financial institution. SHAZAM provides terminal owners direct web access to maintain their service contact information, view dispatch status and redirect dispatches.

Card Services

SHAZAM provides card-issuing financial institutions access to several different types of card programs to serve their market segments, including business debit, consumer debit and various types of prepaid cards. The following are several different types of transactions SHAZAM supports for these card programs:

Withdraw cash

Purchase merchandise with or without cash back

Check account balances

Transfer money between accounts

Make deposits

Pay bills

Send funds to another cardholder

Receive funds from another cardholder or a business

In some cases, card issuers may elect to restrict the transactions allowed to the cardholder using options controlled by SHAZAM at the bank identification number (BIN) or individual card level.

SHAZAM® BOLT$™ mobile for Apple® iOS and Android™ devices allows cardholders to set card alert preferences, obtain real-time card account balances and receive transaction-related email alert messages based on card-level preferences.

Debit card services

A debit card adds the acceptance of signature debit to a PIN-only card. The cards look like a PIN card, but it often has a Mastercard® or Visa® logo on its face. Debit cards are used at merchants and ATMs around the world. SHAZAM®Chek is a dual-message debit card processing service that allows the merchant to obtain an authorization and send completions in subsequent batches. SHAZAM also supports contactless Visa debit card services. These cards are full-sized and include both a magnetic stripe and an embedded contactless chip.

SHAZAMChek cards are used in the following ways:

At ATM and point-of-sale (POS) locations using a PIN

At merchant locations around the world by signing for the transaction like a credit card

Unlike a credit card, the funds are debited from the cardholder’s checking account.


Page 10

SHAZAM offers sponsorship into other networks and keeps no portion of an issuers’ interchange income. SHAZAM’s chargeback department provides dispute resolution experience and support for its debit card issuers.

Plastics management services

Issuers may provide cardholder plastics information to SHAZAM to build plastics database files for fulfillment to card personalization providers. SHAZAM also offers plastics ordering.

SHAZAM offers an interactive voice response (IVR) card activation and customer-selected PIN service called SHAZAM Easy PIN®. The SHAZAM Easy PIN IVR application authenticates cardholders using pieces of their information from the plastics database. Issuer-provided plastics information is also relied upon for address verification, exact expiration date matching and fraud case management services.

SHAZAM has options for plastics maintenance that allow the issuer to transmit electronic batch maintenance files or provide manual data entry through SHAZAM Access.

SHAZAM myPic Studio® allows cardholders to upload images that may be used as the background for their card.

Meta Payments System (MPS) gift card

For the agent gift card program, SHAZAM partners with MPS. With MPS, SHAZAM’s financial institutions pay a startup fee and then collect card income whenever a card is loaded with funds.

POS Payment Services

Through SHAZAM, financial institutions provide retail payment services to merchants for PIN-based and signature-based transactions. SHAZAM’s services allow merchants to accept a variety of card products, including SHAZAM cards, Mastercard and Visa debit and credit cards, other credit cards and electronic benefit transfer (EBT) cards.

Merchant and terminal support

SHAZAM gives financial institutions and their merchants the opportunity to select the following:

- Dial-up or leased-line communications

- Electronic data capture using a touchtone telephone or POS terminals

- Standalone modular terminals or integrated equipment, including electronic cash registers, PC access and Internet processing

- Settlement option choices, including direct credit to the merchant’s account or to another account at the financial institution

SHAZAM provides terminal services and support to merchant customers. Merchant services include:

- Troubleshooting assistance

- Training guides

- Help desk support

- Equipment sales

Gift cards

The SHAZAM gift card provides retailers a solution to their gift program. The plastic, prepaid gift card is a replacement for the traditional paper gift certificate program.


Page 11

Switching Services

SHAZAM serves as a “switch” or method of moving a transaction from a merchant acquirer to an issuer for authorization and posting. SHAZAM’s message switching service provides real-time financial authorization and network settlement for financial transactions, including ATM, POS, EBT and debit cards.

Message switching is the core application that supports SHAZAM products. SHAZAM’s switching services include message switching between the following:

SHAZAM online processors International networks

Major POS acquirer processors SHAZAM authorization services

ATMs connected directly to SHAZAM Prepaid gift card authorization system

POS terminals connected directly to SHAZAM EBT issuers

Regional/proprietary networks Bill payment

Card products Person to person payments

International ATM networks Business to consumer payments

International online POS networks

SHAZAM accepts PIN-based POS transactions from internet merchants using network technology from Acculynk and Adaptive Technologies.

If the transaction cannot be completed within the SHAZAM Network, gateway access is available to other networks, including:

AFFN® Mastercard

American Express® MoneyPass®

Cirrus® Plus®

Discover® Presto!®

Interlink® PULSE®

Jeanie® STAR®

Maestro® Visa

In the event an issuer is unable to respond to an authorization request, SHAZAM is able to intervene on its behalf and verify that the transaction is completed. This “stand-in” service is offered in either positive or negative file mode. A positive file allows limits and balances to be used in the authorization process. A negative file option allows SHAZAM to deny a transaction based upon issuer-provided cardholder lists.

Privileged Status

Privileged Status is a program developed by the SHAZAM Network to help community financial institutions provide their customers with a broad base of surcharge-free ATM locations. The SHAZAM network has approximately 3,100 Privileged Status ATMs.


Page 12

SHAZAM Fraud Protection and Management Services

SHAZAM offers two core services to assist in managing fraud losses: FICO® Falcon® Fraud Manager and SHAZAM Case Management Services. These services are additions to SHAZAM’s suite of fraud risk management tools.

Falcon Fraud Manager

SHAZAM offers Falcon Fraud Manager, a neural network technology that identifies fraud risk by detecting potentially fraudulent PIN-based and signature-based debit transactions. SHAZAM offers both batch and real-time scoring. Real-time scoring allows fraudulent transactions to be denied during the authorization process before the issuer incurs liability.

SHAZAM Case Management Service

SHAZAM offers a 24/7 case management service to monitor suspicious activity and manage fraud cases.

Fraud services also includes the following standard services:

Expiration date checking

CAS authorization matching

Lost or stolen card reporting

Address verification

Card activation

Threshold reporting

Temporary card blocking

In addition, services include the following optional fraud risk management services:

Card authorization blocking

Issuers use SHAZAM Access, a web-based administrative application, to set blocking criteria for cards’ BINs. The maintenance allows the issuer to use a number of criteria including merchant location, state, country, category code, internet, signature-debit or dollar amount. Issuers may exclude cards of VIPs or traveling customers from these blocks using an exclusion list.

Stop payment service allowing an issuer to block installment and recurring payments per cardholder request

Enhanced expiration date checking

PIN verification

Card verification information

CVV/CVC verification

CVV2/CVC2 verification

dCVV verification

Mastercard System to Avoid Fraud Effectively and Visa Fraud Reporting

Mastercard SecureCode and Verified by Visa


Page 13

Scope of Report

This report was prepared in accordance with the guidance in the American Institute of Certified Public Accountants’ guide Applying SSAE No. 18, Reporting on an Examination of Controls at a Service Organization Relevant to User Entities’ Internal Control Over Financial Reporting (SOC 1). The scope of this report includes general computer controls and certain applications and business process controls of SHAZAM, Inc.’s EFT system processed in the Des Moines and Johnston, Iowa, facilities. SHAZAM, Inc. uses the subservice organization First Data Resources to provide authorizations, settlement, reporting, billing and statements for merchant transaction processing. The examination and testing performed did not extend to the controls of the subservice organization.

SHAZAM, Inc. EFT System and Components

The following is a listing of the application systems and related operating systems/databases supporting the services indicated above that are covered within the scope of this report. The EFT system is a set of integrated components that can be subdivided into the following:

Application Purpose Purchased or

Developed Operating System Database

Electronic Funds Transfer—Mainframe

Process ATM and POS transactions based on defined rules set by participating financial institutions. Provide settlement reports based on ATM and POS transactions processed.

Developed IBM z/OS DB2

Electronic Funds Transfer—HP

Process ATM and POS transactions based on defined rules set by participating financial institutions. Provide settlement reports based on ATM and POS transactions processed.

Developed HP Non-stop ISAM

SHAZAM Access Client Web Portal

End user portal and access point to reports.

Developed Red Hat V6 DB2

SHAZAM ACH Web portal used to initiate ACH transactions.

Purchased UNIX UNIX

GIT Manage HP and SHAZAM Access source code.

Purchased UNIX UNIX

IDS Manage EFT mainframe source code.

Purchased IBM z/OS DB2

The additional applications/utilities listed below are mentioned in Sections III and IV of this report and may support some facets of the delivery of the services described. These utilities are covered within the scope of the report to the extent they support achieving the control objectives and were not subject to IT general controls testing.


Page 14

Application/Utility Purpose

Falcon Fraud Detection System

The Falcon Fraud Detection System is a purchased software system used to establish rules to track, manage, alert and deny transactions based on behavior and / or financial institution direction.

eTrust eTrust is a purchased CA product that provides file-based access control for UNIX systems.

CA AuthMinder/ RiskMinder/ SiteMinder Suite

A suite of authentication systems known as AuthMinder, RiskMinder and SiteMinder.

Strong authentication of legitimate users is administered through CA® AuthMinder™ Versatile Authentication Server and CA RiskMinder™.

CA SiteMinder® authorization product controls access within the portal, restricting access to financial institution information through the use of Lightweight Directory Access Protocol (LDAP) attributes.

Siebel This customer relationship management (CRM) tool is used for site identification, trouble ticketing, reporting and vendor response tracking.

SolarWinds SolarWinds® is a monitoring tool used for SHAZAM’s frame network, broadband and cellular ATMs.

SonicWALL GMS This is the firewall and IPS monitoring system.

Goldleaf Warehousing application in support of SHAZAM ACH. This application pulls files from the directory and imports them into the data warehouse. The warehouse pulls batches with an effective date of the next business day or earlier to send to the Federal Reserve

GoldenGate Software used at SHAZAM for real-time data integration and continuous data availability by providing continuous data synchronization across heterogeneous environments.

NetBatch A job processing tool used to schedule and process transactions.

NetPass A tool utilized with HP SafeGuard to enforce password integrity.

IBM Security Access Manager (ISAM)

A purchased product utilized to enforce password requirements for SHAZAM ACH and allow SHAZAM to set password configurations.

Relevant Aspects of the Control Environment, Risk Assessment Process, Information and Communication Systems and Monitoring Controls

Control Environment

A company’s control environment reflects the overall attitude, awareness and actions of management, the board of directors and others concerning the importance and emphasis given to controls in the company’s policies, procedures, methods and organizational structure. The following provides an overview of the internal control structure.

Management Oversight

SHAZAM management is responsible for directing and controlling operations and for establishing, communicating and monitoring control policies and procedures. SHAZAM senior management meets biweekly to discuss control issues, operations and financial performance. Organization values, policies and a code of conduct are communicated to personnel through the employee handbook.

Upon employment, and when a change is made to the employee handbook, employees sign an acknowledgement form noting they have online access to the handbook and agree to comply with the policies set forth. Annually, employees sign an acknowledgement form noting they have received and read the organization’s security and privacy policies.


Page 15

Organization and Administration

The organizational structure of SHAZAM, which provides the framework for planning, directing and controlling operations, uses an approach whereby personnel and business functions are segregated into departments according to job responsibilities. Job descriptions are reviewed by management when significant changes in duties or responsibilities occur. During the period January 1, 2017, to October 31, 2017, no significant changes in duties or responsibilities occurred.

SHAZAM personnel are assigned responsibilities based on job descriptions defined within SHAZAM’s organizational structure (providing for segregation of duties). Client support representatives are available to assist financial institutions, merchants and cardholders. These representatives serve as the primary contact between SHAZAM and the financial institutions and are responsible for working with the financial institutions to address concerns in the ever-changing financial institution industry.

SHAZAM is divided into separate organizational elements reporting to the president and chief executive officer (CEO). Separation of duties is maintained between and within the following organizational elements with jobs defined by job descriptions:

Corporate

- Audit

- Compliance

- Enterprise risk and security

- Security operations

- Risk management

- Risk services

- Legal

Facilities and mailing services

Finance services

- Accounting and finance

- Market intelligence and data analytics

- Enterprise brand strategy

- Enterprise processing strategy

- Acceptance

Customer operations

- Chargeback

- Client support (EFT)

- Core implementations and support

Core client support

Core implementations


Page 16

- EFT implementations

- Fraud operations

- Professional services

Customer operations professionals

Training

Vendor relations

Human resources

Information technology and business development

- Applications development

Core development

EFT distributed services

EFT OLTP services

Enterprise IT architects and SMEs

Enterprise project management

Quality assurance and certification

Siebel development

Enterprise systems

Business project management and acquisition integration

- Infrastructure

Computer operations

Core data center

Database administration

Network services (WAN)

UNIX technology

Production support

Systems programming

- Windows technology and desktop

- Product development

Network products


Page 17

Sales and marketing

- Marketing and sales support

Corporate communications

Marketing

Merchant sales and services

Sales support

Public relations

Sales

- Client retention and growth (CRG)

- New business

New hires are subject to criminal background checks and verification of previous employment and educational background prior to their employment. New hires are also subject to a check against the Terrorist Watch List (Social Security number check). Additionally, new hires are checked against the list of persons who are or were assessed civil monetary penalties, or who have been permanently removed, prohibited or restricted from engaging in banking or otherwise worked in or owned a financial institution prior to employment. Certain positions may also be subject to supervisor and peer reference checks.

Positions requiring higher-level security, risk, financial and access responsibilities are subject to credit checks. These positions include the executive vice president and chief financial officer (CFO), the senior vice president and controller and the senior vice president of enterprise risk and security. Employees complete a security awareness training program annually and sign a document indicating that they received and comply with SHAZAM security and privacy policies.

SHAZAM employees do not initiate or modify transactions in the defined course of their duties.

Board of Directors

SHAZAM is governed by a board of directors representing insured depository financial institutions, state financial institution regulators in Iowa and financial institution trade associations. The board meets semiannually to discuss matters pertinent to SHAZAM and review financial information. The board’s Executive Committee meets periodically throughout the year overseeing senior management and its operations.

The board’s Risk and Audit Committee meets at least twice per year and on an “as-needed” basis. The committee is responsible for 1) reviewing the results of external audits and examinations; 2) reviewing the effects of accounting and regulatory pronouncements on SHAZAM; and 3) overseeing internal audit activities and reviewing the findings and recommendations identified as a result of internal audits.

The board of directors and management review, approve and advise data center management regarding corporate plans and policies and monitor the company’s progress.

Budgeting

The budgeting process occurs annually, typically from December through May of the prior fiscal year. The budget begins with a zero-base draft of revenues and expenses. Sales areas are in charge of creating the revenue budget, and department managers are in charge of creating the expense budget. These budgets are reviewed through three draft/revision cycles by upper management and then submitted to the Finance and Audit Committee at the end of May/beginning of June for an in-depth review and approval. Upon approval by the committee, it is submitted to the board of directors for ratification.


Page 18

Risk Assessment Process

SHAZAM has placed into operation a risk assessment process to identify and manage risk that could affect its ability to provide reliable transaction processing to its financial institutions. This process requires SHAZAM to identify risks based on:

Management’s internal knowledge of operations and the EFT industry

Input received annually from management and internal audit during the annual enterprise-wide risk assessment of SHAZAM’s operations

Input received annually from its external auditors based on the external auditors’ examinations of the operating environment

If risks are identified, management is responsible for implementing measures to monitor and manage these risks .

Financial Soundness Evaluation

Applicants participating in signature\dual message transaction programs are subject to a financial soundness evaluation based on predefined objective criteria. These evaluations are reviewed by SHAZAM senior management and ratified by the Risk and Audit Committee of the board as part of the process for approval of participation. Participants are subject to ongoing evaluations of financial soundness according to the same evaluation criteria. The committee reviews these evaluations, and based on its direction, management takes action when indicated by the evaluations.

Information and Communication Systems

EFT System

The EFT system includes the following components:

Authorization services

ATM services

Card services

Switching services

Privileged Status®

Fraud protection and management services

Description of SHAZAM’s Processing Environment

The EFT systems and development, maintenance and testing activities are processed on IBM® and HP® platforms. The IBM platform consists of two IBM z114 mainframe computers running IBM’s z/OS operating system.

One mainframe, including the associated front-end processors and other peripheral equipment, is used for online real-time EFT switching activities. Online real-time functionality is provided through IBM’s Airline Control System (ALCS). The front-end processors run under proprietary communication processing and network processing operating systems. The offline processing is handled by mainframe, UNIX and Linux servers.


Page 19

The redundant mainframe processors and related peripheral equipment provide backup processing support to the online system. Logical access security to these systems is provided by IBM’s Resource Access Control Facility (RACF®) access control system.

The HP environment consists of an HP Integrity NonStop processing platform running the J06.18 operating system. Similar to the IBM system, the HP runs proprietary communication processing and network processing application systems. Logical access security to these systems is provided by the SafeGuard and NetPass access control systems.

Report/data transmission is facilitated through a number of internally developed and vendor-provided solutions, including the SHAZAM Access web portal, batch plastics, SHAZAM ACH, bulk data and Connect Direct.

SHAZAM supports EFT processing for approximately 160 data processing centers (DPCs). Terminals may be connected directly to SHAZAM or indirectly through one of the DPCs.

Participating financial institutions and merchants select, acquire and maintain their own ATM and POS equipment; however, SHAZAM certifies terminal equipment to validate it meets SHAZAM standards regarding compatibility with the company’s hardware and software. SHAZAM processes over 70 million switched transactions per month over frame-relay, dedicated and dial-up telephone lines.

Monitoring Controls

Management and supervisory personnel are responsible for monitoring the quality of internal control performance as a part of their activities. An internal audit function is in place to assist with monitoring and conducting specific internal audit projects based on the annual enterprise-wide risk assessment of SHAZAM’s operations. Internal audit and compliance monitors and evaluates the performance of subservice organizations through review of SOC reports. Results of specific internal audit projects are reported to the Risk and Audit Committee.

To assist in this monitoring, SHAZAM has developed reports and alerts that monitor the functioning of the EFT systems. To complement these measures, exceptions to scheduled processing related to hardware, software or procedural problems are logged, reported and tracked until resolved. Management reviews reports daily to determine whether action was taken and issues were resolved.

Management performs validation testing of key report functionality and transaction processing as part of the normal course of business when onboarding a new client. During the implementation process, management generates reports with new client data to evaluate the completeness and accuracy of the reports, and in some cases, performs recalculations of report transactions.

Information Technology General Computer Controls

Information Security

Logical Access Controls

SHAZAM has policies and operational procedures that define security administration and end user responsibilities. SHAZAM’s security operations department is responsible for establishing and overseeing logical security based on established policies and access assignment levels approved by management under the concepts of least privilege and role-based access controls. Security operations is also responsible for monitoring access violations.

SHAZAM’s security operations team and network administrators maintain the system for monitoring and analyzing access to data and possible security alerts. Intrusion prevention and detection systems have been implemented to alert SHAZAM personnel regarding potentially unauthorized access attempts. These systems log system events and filter them through a security event monitoring correlation engine and log centralization appliance that allows for analysis of corporate systems.


Page 20

The Network Operations Center (NOC) gathers statistics via Simple Network Management Protocol (SNMP) on areas such as network bandwidth usage, web and virtual private network (VPN) activity, attempted intrusions and firewall status. A report of the statistics is generated for review by managed firewall services customers on a monthly basis.

Employee Access

Upon notification from human resources that a new employee has been hired, the supervisor is responsible for requesting physical and logical access by completing the System Access Form within the internal customer relationship management (CRM) tool. The supervisor selects systems and applications the employee will need to perform his or her assigned duties.

An electronic copy of the request form is sent to security operations via the CRM application. Security operations review the request and, once approved, grant the request and establishes access to the systems and applications listed on the form. When an existing employee needs his or her system access updated due to a transfer, that employee’s supervisor follows the same procedure described above. Security administrators remove or disable employee logical access when notified of employee terminations.

An annual security certification is required of SHAZAM employees. This includes their acknowledgment via a standard form to confirm the employee has reviewed and will comply with the security policies. This annual certification is integrated with an employee security awareness training program that employees are required to complete. This program consists of a series of brief educational videos with quizzes following each module. Employees are required to complete their assigned videos and successfully pass the quizzes.

Access to program and data files by internal users, financial institutions and cardholders is controlled through a combination of hardware and software systems, including:

Local area network (LAN)

SHAZAM’s LAN employee access is controlled by the Microsoft® Active Directory®. Server-based controls include policy and operational procedures for administration, including server-hardening procedures for Windows servers, patch management processes and the granting, adding and rescinding of user access. Access rights are restricted and security policy settings are controlled by the network administrator. Logical access to Active Directory is controlled through an authentication mechanism and includes the following system parameters:

- Minimum password length of 12 characters

- Password expiration in 90 days

- Password complexity requirements, including the use of alphabetic, numeric and special characters

- A clipping level set to lock out an ID after five invalid password attempts

- Password history of eight is maintained

The eTrust application is used to restrict file permissions to the UNIX-based systems (RedHat and AIX). eTrust automatically sends email notifications to the UNIX technology group for review of failed access attempts.

Network infrastructure

Management has deployed a network infrastructure that segregates the network based on business function. Redundant firewalls control access between various network segments, extranets and internet circuits. Firewall logs are maintained and automatically monitored. Port security is in place, along with a guest wireless LAN, to allow registered guest users to access the internet while inside a SHAZAM facility while remaining segregated from the internal SHAZAM computing network.


Page 21

Host access

Host access security over programs, data files and ALCS is provided through RACF on the IBM system, and through SafeGuard on the HP system. The configuration of RACF and SafeGuard is set through security parameters established by the systems and security departments.

Security personnel are responsible, in conjunction with the systems administration team, for maintaining RACF, SafeGuard and web portal access rules and data access restrictions based on authorized requests. Security personnel remove employee logical access based on communications of employee terminations received from human resources. Security personnel monitor RACF and SafeGuard internal security violation reports using their security information and event management tool, and follow up with investigation if necessary.

- RACF controls access to 1) ALCS system commands; 2) online programming facilities (for example: TSO); 3) staging and production source and object code libraries; 4) tape and disk-resident data files; and 5) other system software, facilities and utilities. This control is provided by restricting access to protected resources and enforcing authentication requirements to at least adhere to the following:

Minimum password length of eight characters

Password expiration in 90 days

Password complexity requirements, including the use of alphabetic, numeric and special characters

A clipping level set to lock out an ID after four invalid password attempts

Password history of eight is maintained

- SafeGuard and NetPass controls access to files, devices, processes and objects. This control is provided by restricting access to protected resources and enforcing authentication requirements to at least adhere to the following:

Minimum password length of 12 characters



A clipping level set to lock out an ID after four invalid password attempts

Password history of eight is maintained

Switch processing system

The switch processing system controls access to the online system to those ATM, scrip-issuance and POS terminals defined to the system’s front-end processors. These terminals are uniquely identified to the front-end processors based on terminal serial number, merchant number and the port to which the communication line is connected. The terminal serial number and merchant number are included in transaction messages submitted by a terminal for use in transaction validation and message routing. Messages exchanged with these terminals use a predefined format and sequence.

The switch processing system controls access from participating financial institution DPCs by restricting communications to transactions in predefined message formats. These communications are restricted to messages received via dedicated, leased telephone lines.

Financial institutions submit certain predefined file maintenance transactions using various SHAZAM internally developed and vendor-supplied solutions.


Page 22

Web portal

SHAZAM’s web portal applications are called SHAZAM Access and SHAZAM ACH. The applications control access to financial institution information and ACH submissions, and are located at www.shazam.net. Defined user roles control access permissions within the SHAZAM Access web portal. Security safeguards include:

- Transport Layer Security (TLS) communications on the front-end that require data transmitted over the internet to be sent encrypted

- Authentication of authorized users through CA® AuthMinder™ Versatile Authentication Server and CA RiskMinder™ for SHAZAM Access and through IBM Security Access Manager (ISAM) for SHAZAM ACH

- CA SiteMinder® authorization product that controls access within the SHAZAM Access portal, restricting access to financial institution information through the use of Lightweight Directory Access Protocol (LDAP) attributes

- The enforcement of password controls that have been defined within the CA authentication systems for SHAZAM Access, such as:

Minimum password length of eight characters



A clipping level set to lock out an ID after five invalid password attempts

- ISAM product that controls access within the SHAZAM ACH portal, restricting access to financial institutions’ ACH origination submissions, enforces password controls, such as

Minimum password length of 14 characters



A password history of six

- User roles as defined by SHAZAM within the SHAZAM Access and SHAZAM ACH applications

- Monitoring of host- and network-based intrusion prevention and detection systems

SHAZAM establishes financial institution security administrators who are responsible for safeguarding the use of SHAZAM Access and SHAZAM ACH for report and data transmissions after completion of an authorization form from the requesting client.

Monitoring

The NOC monitors the managed devices through the SonicWALL® Global Management System (GMS). This tool monitors communications via ping testing and gathers statistics via SNMP on areas such as memory use, buffer hits/misses, packet loss and CPU use. SonicWALL is configured to send automated alerts via email to the NOC and to page the on-call technician when event thresholds are met.

http://www.shazam.net/


Page 23

Network and security administrators record suspicious activity in the incident management system for resolution. RACF internal security violations related to system access attempts are recorded and available for review by the security team.

Physical Access Controls

SHAZAM maintains two facilities in the Des Moines, Iowa, area. The production data center is located in a single-story building in Johnston, Iowa. SHAZAM is the sole occupant of the building. SHAZAM’s business facility in Des Moines houses the backup data center.

Access to the buildings and the data center is restricted by a card access security system 24/7. Physical access within the buildings is restricted based on job role under the concept of least privilege to limit access and maintain segregation of duties. SHAZAM has installed a closed-circuit television (CCTV) camera system in both buildings to detect suspicious activity. The cameras are monitored 24/7 by the computer operators, and both facilities are monitored during business hours by reception and security operations staff members.

Visitors to the facilities are required to have an appointment and sign in at the reception area, wear a visitor’s badge and be escorted by a SHAZAM employee while inside the facilities. SHAZAM uses electromagnetic locks, controlled by proximity card keys that have been installed on building entrances and the doors that separate the main entrances of the buildings from sensitive areas (including the data centers).

The security operations department maintains the proximity card key system. Access cards for new employees and changes to access are requested by the employees’ departmental managers through an electronic system access form. A review of proximity card access is performed by corporate security on an annual basis. Terminated employees are required to return their cards as part of the exit interview. Additionally, a notice is sent by human resources to the security operations department for deletion of physical and logical access rights. Building access rights are revoked once the terminated employee has left the facility.

Computer operations, production support, systems and network services personnel, as well as the CEO and certain other personnel, have been granted access to the data centers. Visitors and other employees are escorted by authorized personnel within the data centers. Computer system consoles are housed in a separate room within the data center, with access to the room restricted by an electromagnetic lock.

Systems Development and Change Management

Change Management

SHAZAM management has established an electronic change management process that controls modifications to hardware, software, firmware and data documentation that are undertaken by the IT departments. Through both the project gating process and a project planning committee (represented by areas of the company), changes are discussed and reviewed by both the business and technical departments in the organization on a weekly basis.

In accordance with the change management process, the departments that handle modifications to hardware, software, firmware and data documentation have written and electronic change management procedures tailored to the department’s activities. The procedures cover pertinent change aspects relating to change description, content of the change, change testing, deployment procedures, notifications and approval, responsibilities, high-level impacts, customer impacts and other information considered pertinent to the change at hand.

Changes to the systems require accompanying documentation and electronic signatures by management. The hardware, software, firmware and data documentation changes addressed by the change management process are scheduled in Siebel and the Microsoft® Outlook® calendars for the date requested and are reviewed daily by personnel and managers who are involved with, or help to oversee, the item or area subject to the changes.


Page 24

Systems Development, Maintenance and Documentation

SHAZAM has established a systems development methodology for use in development and maintenance projects to guide personnel in the design, testing and implementation of system modifications. While procedures may vary slightly for smaller projects, the same general approach is used.

Project Request and Product Concept Document

A request for a change to an existing program, or to develop a new program, is submitted in writing on a project request form and is approved by management. System changes may also be initiated due to system errors or processing problems that are documented on an internal service request (ISR). The programming team member evaluates ISRs to determine if the underlying issue is the result of a production error or standard enhancement. If a project enhancement is required, a project request form is completed and follows the project development methodology.

For approved projects, project requirements are developed and accompany the project through its development cycle to help determine whether the requester’s objectives are met as development/ maintenance progresses. The project sponsor and senior management approve the project requirements before prioritization of the project. If the project is technically driven, the product concept document may be replaced by a project impact statement. The SHAZAM Enterprise Management Team, made up of senior vice presidents, meets weekly to provide oversight, prioritization and to authorize the start of enterprise projects resulting in changes to production.

Functional Business Requirements Document and Technical Response Document

Following the definition of the project’s requirements, the functional specifications are developed and updated in a business requirements document to communicate the functionality requested to both internal and external users. The project sponsor and senior management approve the functional specifications in the business requirements document prior to the development of technical specifications.

The technical response and project-level design documents include such items as system designs and test plans. The project sponsor and IT management approve the technical response and project-level design documents. If the project is technically driven, the project requirements and technical response documents may be replaced by a project impact statement.

Code Development and Testing

Upon completion of the detail design documents (functional and technical specifications), code development, maintenance and testing begins in a separate test environment. For application programming changes, programmers are required to use automated library management tools. These tools help manage the software development process from the time code is checked out to implementation. Access to library management tools is limited to authorized users. For Java™ development and C++, programmers are required to use GIT for source code management, and the ITS Development System (IDS) is a library management tool used for the IBM Mainframe programs.

GIT is the source code management tool for Java and C++ code. Access to GIT is restricted to authorized users through the GIT security access model. Developers have a unique user ID that gives them access to check out code and commit code changes back into GIT. Their user ID also allows them to build packages based on the code in GIT and deploy that code to their development and test environments. After developers complete testing, they notify production support personnel via email to vault the package that the developers have built and tested in development. The email includes the change number, package identification and any pertinent instructions related to the vault process.

Once the package is vaulted, the package cannot be changed. QA will install the package from the vault into the test environment and complete testing. Once testing in QA is complete and the package is ready for production, the package is installed in production from the vault by production support specialists who do not have access to change source code. Development does not have access to production and cannot


Page 25

install packages in production. Those implementing in production do not have access to the development environment or the ability to check code into GIT. Programs to be implemented are tested; a record of testing is maintained in IT change request forms. For project-level changes, testing documentation is retained in the online project documentation repository.

IDS is a library management tool used for the IBM mainframe programs. IBM mainframe developers have a unique user ID and authenticate through RACF to access IDS (on Mainframe TSO) to check out code and develop the requested change. Developers can specify which of the two test environments they want to check out the code to, QA and/or parallel. Once they have made the change and tested in development, they check the code back into IDS for review and approval. When the code is ready to be implemented to production, the developer checks the code back into IDS and IDS generates a request number. An independent developer reviews and approves their request using the request number. Once reviewed and approved by a second developer, they create a Change Control Form through Siebel that requires several approvals ranging from managers, architects, systems, VP of applications, etc., based on the level of changes. Once the Change Control Form is approved, the actual production implementation is completed by the production support team. Developers do not have access to implement code to production.

Because of their nature, most changes to system software originate within a technical support area. The systems group develops a business case, performs budget research and obtains management approval for system changes. New system software is tested in conjunction with third-party products and application programs prior to its implementation in a test environment.

QA will install the package from the vault into their test environment and complete testing. QA testing can include integration, regression and end user testing. Once testing in QA is complete and the package is ready for production, the package is installed in production from the vault by production support specialists who do not have access to change source code.

IDS provides the similar code management as GIT, except it is used for the legacy IBM mainframe developers. Each IDS developer has a unique user ID that allows them to create an IDS package to be deployed to production, but those user IDs do not have access to deploy those packages to production. Developers are able to check out source and submit changes to Production Support for implementation, but are not able to update production libraries. Production support personnel can implement the new code to production libraries. Systems personnel manage IDS and RACF access lists.

Approval Process

In the event emergency changes are needed to application systems, designated applications personnel are contacted to correct the issue. In these instances, the documentation and review procedures are consistent with those previously noted. However, they are generally performed in an accelerated manner.

Implementation

When a project is ready for implementation (based on the existing process), the programmer schedules the project to either the online (live) calendar or offline (batch) calendar and the HP® production or UNIX production calendar, as applicable. Postings to the calendars are reviewed during the daily production management meeting. Representatives from impacted departments review the calendars on SHAZAM’s intranet prior to the meeting and attend the meeting if they have questions or concerns regarding a change being implemented.

The programmer moves the program source code from the development libraries to the staging libraries. Production support personnel or UNIX team members are responsible for moving the source code from the staging libraries to production and compiling the source code into object code. Programmers do not have update access to the production libraries or production systems, and programmers cannot approve their own programs. Access reviews performed on SHAZAM systems—including access to the IBM and HP production environment, IBM and HP source code and the SHAZAM network—are reviewed and monitored by internal audit on a semiannual basis.


Page 26

For the GIT implementation process, the build can be performed by an automated process or developers that have access to development and GIT. When a build in development is ready to move out of development into QA and eventually into production, that build is moved into the vault as an integration package. A request is sent to production support to vault the integration package. Developers cannot vault the integration package, which restricts them from introducing code into the QA, parallel or production environments. Production support staff members cannot create an integration package, which restricts their ability to assemble to assemble code for introduction into QA, parallel or production environments. Once a package is vaulted, it cannot be changed and will be tested by QA and eventually deployed to production.

For the IDS implementation process, similar to GIT, only developers have access to create a deployment, and once created, that code is locked and cannot be checked out or modified by another developer. Those implementing the code do not have access to check out the code or to request an integration package for implementation.

Infrastructure changes

SHAZAM has a documented change management policy that outlines the process for authorization and implementation of modifications to hardware, software and data that are undertaken by the IT departments. Additional documentation is in place to outline the specifications for building and configuring new Windows- and UNIX-based systems. Changes to system hardware are requested and documented within Siebel. The requested change is reviewed by management and approved prior to implementation.

Computer Operations

The computer operations department is responsible for monitoring system hardware and software on IBM®, HP® and client server platforms. In addition, the computer operations department monitors and provides operational input for production and test applications. SHAZAM staffs its operations department 24/7 (including holidays).

Operations Job and Program Scheduling

Automated scheduling and submission systems are used to submit production batch programs on both the IBM and HP systems based on predefined processing sequences. Production support is responsible for maintaining the automated schedule based on authorized requests and monitoring deviations from scheduled processing using system-generated reports.

Initial access to the scheduler on the IBM system is controlled by RACF®, while access to functions within the system is controlled by native security. Production support maintains the native security parameters. Access to the scheduler on the HP NonStop system is controlled by SafeGuard, which is similar to RACF on the NonStop platform.

Computer Operations Monitoring

Operations staff members are responsible for monitoring multiple systems within SHAZAM’s environment. These include monitoring internal production systems (OLTP/online and offline/batch) for the IBM, HP and distributed environments, as well as acquiring financial institution ATM terminals. The system automatically records processing activities on the system’s console log that is displayed on the system console. Computer operations personnel monitor daily and automated operations to verify completion of scheduled processing and document verification on processing checklists. Operations personnel create entries in a problem reporting system to track, record and resolve production systems’ schedule deviations. Operations also has defined escalation procedures to address operation abnormalities.

ALCS

ALCS is the software used for online real-time EFT switching activities in the IBM environment. Commands are entered into ALCS through the use of the Prime Computer Room Agent Set (CRAS) terminal functionality by using Vista (Windows tn3270 emulation software). Processing on ALCS is


Page 27

monitored by the operators viewing two ALCS logs containing the daily output created from programs, communication and other activity taking place within ALCS. These logs are monitored by the operations team for ALCS system, application program error messages or dumps. Additionally, a predefined run log containing daily, weekly, monthly or other specified events and commands is used daily for execution and validation of these manual processes.

MVS Offline (Batch)

SHAZAM uses Zeke for its automated scheduling and submission system for production batch programs on the offline system and monitoring whether the batch programs were completed successfully. Unsuccessful executions are identified and resolved by operations staff members. Operators assigned primary and secondary monitoring responsibilities use the Zeke software accessible via an MVS TSO session running on Vista (Windows tn3270 emulation software) on a PC workstation. Non-Zeke-controlled batch programs are reviewed by the operators for errors.

Manual Logs

A predefined run log containing daily, weekly, monthly or other specified schedule events or commands is used to monitor and validate that manual processes have been executed. The logs are used to cover batch transactions on the system. Logs contain designated areas for each shift to initial as completed by one of the senior personnel for each team. Processing checklists are reviewed daily by senior computer operations personnel for resolution of issues completeness. Backup personnel are identified in case of unavailability of the primary personnel.

The logs are completed by computer operations personnel on a daily basis. Senior computer operations personnel review the log on a daily basis to verify it was completed. Production support personnel monitor deviations from scheduled processing daily and document deviations in the daily shift turnover log.

HP NonStop (OLTP and Batch)

SHAZAM uses several tools and applications to monitor the HP environments. These include Automated Operator (AO), ObjectMAP and MOMI as well as internally coded applications, Operator Interface and SwitchTools. These tools are used to monitor the real-time activity of the applications, system software and hardware based on criticality parameters (for example: limited disk space). Most of these tools and applications are set up to automatically alert staff members when a defined parameter is met. Batch processing on HP NonStop is controlled through a NetBatch job scheduler. The operations area also monitors the event management system (EMS) real-time activity logs for errors.

Distributed Systems

Distributed systems events, typically from UNIX servers, are integrated with the HP Nonstop EMS system and are monitored through the HP Nonstop EMS console and escalated via notification emails to operations personnel.

GoldenGate software is used at SHAZAM for real-time data integration and continuous data availability by providing continuous data synchronization across heterogeneous environments. Operations is responsible for error monitoring and escalation.

There are a number of tools used to monitor network performance. SolarWinds network monitoring software is a primary tool used to assist the operations team in quickly detecting and diagnosing network performance issues and outages, as well as other definable monitors and alerts for Windows-related issues.


Page 28

Escalation Policies

The computer operations department has established escalation procedures to address system and application errors or issues. Severity levels have been established to dictate error escalation. Errors and issues considered critical are escalated immediately by a call to the primary on-call support person. Errors and issues considered noncritical are not escalated by a call to the primary on-call support person until the beginning of the next normal business day. Follow-up is then performed the next day as specified in the documentation. Procedures also document secondary on-call support and management escalation. Errors and issues escalated to support staff members are documented.

A Siebel ISR is created by the operator on duty. Details of the error are included, and the error and issue are then assigned to the on-call support person where they will research the issue and document resolution within the ISR.

Network services also track and resolve system and network performance issues within Siebel.

Backup Media

SHAZAM has documented backup procedures to outline the backup process. SHAZAM utilizes a virtual tape library (VTL) system. The VTL system is federated between the Johnston data center and Des Moines backup data center to maintain multiple copies of the data. Data backups for Windows, UNIX, SHAZAM Core Services, DCC (i5/AS400), HP NonStop and IBM/z/OS are initially written to the VTL on a daily basis.

The operating systems, application programs and data files for the online (ALCS and HP NonStop) and offline (MVS) systems are backed up daily. At a minimum, a 16-day retention period is maintained for the IBM data backups, and a minimum of five days for the HP Nonstop Transaction Management Facility (TMF) audit trail and online dumps of audited files on the HP NonStop. HP Guardian backups of non-audited files are retained for a minimum of eight days. End-of-month backups on the IBM system are retained for one year. SHAZAM uses media management systems to monitor and track backup creation and maintenance. Computer operations track completion of backup procedures on a daily basis within a processing checklist, which is used to document resolution of processing errors for the day. Windows, UNIX and i5/AS400 files are also backed up on a daily basis.

NOC

The NOC is responsible for monitoring communication links between the host and remote ATMs and data processors. NOC personnel are responsible for the daily monitoring of hardware and communication problems using various tools and NOC personnel address alerts as they are received. Issues that can’t be addressed immediately are logged in the daily turnover sheets in the comment section and a Siebel ticket is issued to ensure completion by the next shift.

Network Monitoring

Siebel

Siebel is a customer relationship management (CRM) tool used for site identification, trouble ticketing, reporting and vendor response tracking. Troubleshooting activity is entered and tracked through Siebel. Siebel also allows employees to see past trouble history and technician performance. Information such as addresses, circuit IDs, protocol and modem type are referenced in Siebel by the NOC team to identify the location and trouble type associated with the issue.


Page 29

Multiprotocol Label Switching (MPLS) Network

SolarWinds and Multi-System Online Measure Interface (MOMI) are examples of monitoring tools used for SHAZAM’s frame network. SolarWinds network monitoring software is a primary tool used to assist operations staff members in detecting and diagnosing network performance issues and outages. These tools alert the NOC team of issues at certain locations. NOC personnel address alerts as they are received. The team uses different router commands to step through the troubleshooting.

Packet Internet Groper (Ping) and Secure Shell (SSH) commands allow technicians to access the local and remote routers’ configurations and interfaces to isolate and correct issues. Issues that cannot be addressed immediately are logged in the daily turnover sheets in the comment section and a Siebel ticket is issued to ensure completion by the next shift. Shift turnover logs are created Tuesday to Sunday. Monday is included in Tuesday’s shift turnover log.

Broadband ATMs

The NOC uses SolarWinds to monitor ATMs connected to SHAZAM via broadband methods. These tools alert the NOC team of issues at certain locations. NOC personnel address alerts as they are received.

Cellular

The NOC uses SolarWinds to monitor communications to cellular-connected ATMs. SolarWinds alerts the NOC to loss of communications with cellular devices.

Data Processing Centers (DPCs)

The NOC uses Operator Interface to monitor real-time queues for the data processors. The department monitors for abnormal activity and contacts support people when needed.

Escalation Policies

SHAZAM has established defined escalation policies to address NOC activities. These escalation procedures address router and modem replacements, telecommunications activity and internal communication. Defined time periods and escalation contracts outline response procedures.

Management and associated departments receive notifications of large outages, as well as major account outages, at the time they occur. The department is notified through emails of updates that transpire through the troubleshooting process. Leads and managers are notified through Siebel when tickets are not being updated within a defined time frame.

Application and Business Process Controls

The following section describes controls over the automated application processing and business processes for processing transactions through SHAZAM, Inc.’s EFT system and providing reporting to user entities. EFT systems are a suite of services that provide:

Cardholders the ability to execute debit and credit card transactions

Merchants the ability to execute PIN-debit and signature-based transactions

Financial institutions with a method for transmitting and originating ACH items to and from the Federal Reserve

Financial institutions with daily settlement processing

The relevant services and processing provided are summarized below.


Page 30

Switch Processing

SHAZAM’s message switching service provides real-time financial authorization and network settlement for financial transactions, including ATM, POS, electronic benefits transfer (EBT) and debit cards. Message switching is the core application that supports SHAZAM products. SHAZAM’s switching services include message switching between the following:

SHAZAM online processors International online POS networks

Acquirer processors International networks

ATMs connected to SHAZAM SHAZAM authorization services

Regional/proprietary networks Prepaid gift card authorization system

Card products EBT issuers

International ATM networks Home banking processors for bill payments

Providers of business-to-consumer payments Providers of person-to-person (P2P) payments

SHAZAM serves as a “switch” for the purpose of moving a transaction from an acquirer processor to an issuer processor (also known as a DPC) for authorization and posting. If the transaction cannot be completed within the SHAZAM Network, gateway access is available for routing to other networks.

The SHAZAM switch processing system permits the cardholders of financial institutions to use EFT terminals (for example: ATMs and POS terminals) that are owned or supported by other financial institutions. The switch processing system routes transaction requests and the related transaction authorization/denial response messages between terminals and the corresponding cardholder financial institution DPC (cardholder DPC) for purposes of cardholder validation, transaction authorization and recording. A daily settlement file is provided to the Federal Reserve, and settlement/transaction activity reports are provided daily to the acquiring financial institutions and cardholder financial institutions to allow for settlement and balancing of the transaction activity. As a matter of policy, SHAZAM does not own EFT terminals.

Switch-In-Front (SIF) and Switch-Behind (SBH) Terminals

Terminals are connected to SHAZAM in one of two ways: SIF or SBH. SIF terminals are directly connected to SHAZAM. These transactions are routed by SHAZAM to the cardholder DPC or the CAS system if the cardholder financial institution is not connected to a member DPC for authorization/denial. The cardholder DPC returns a response message to SHAZAM that in turn routes the transaction response back to the originating terminal.

SBH terminals are connected to a DPC (terminal DPC) of the owning or servicing financial institution (acquiring financial institution). If the cardholder at a SBH terminal is a customer of a financial institution served by the terminal DPC, the transaction is processed at that DPC and the transaction is not sent to SHAZAM. If the cardholder is not a customer of a financial institution served by the terminal DPC, the transaction is routed through SHAZAM to the cardholder DPC or the CAS system for authorization/denial. The cardholder DPC sends a response back to SHAZAM that in turn routes the transaction response to the terminal DPC. The terminal DPC is responsible for routing the response back to the originating terminal.

In the event a cardholder DPC is unable to respond to an authorization request, SHAZAM is able to stand in and authorize or deny the transaction on behalf of the cardholder DPC. This stand-in authorization service is offered in either positive or negative file mode. A positive file provides cardholder-level limits to be used in the authorization process, with the option of including account balance information. A negative file is a listing of hot cards and warm cards that will be denied access during stand-in. Financial institution-level limits are established to allow access for good cards during stand-in authorization.


Page 31

Transactions

The transaction messages received by SHAZAM during switch processing include the terminal identification number, acquirer processor sequence number, posting date (optional), cardholder primary account number (PAN), encrypted PIN block, transaction codes and transaction amounts. SHAZAM adds a system sequence number, originator number, cardholder identification and the terminal location description to the message. The cardholder DPC provides a response code in the returned message indicating receipt or error of the transaction.

An ATM or scrip-issuance transaction is initiated at a terminal by a customer inserting a debit or credit card into the terminal and entering a PIN and a transaction request. The terminal encrypts the PIN, and the transaction and encrypted PIN are sent to the switch. SHAZAM validates the card account and PIN and sends the transaction request to the CAS system or to the cardholder DPC for authorization.

POS transactions are processed in much the same manner as described above, except as follows:

The merchant is required to press a key on the cash register/terminal to enter the transaction code.

The customer is required to slide a card through the terminal and enter a PIN (except for credit transactions and qualifying low-dollar purchases that do not require a PIN).

For POS transactions at gas pumps, a specified or default debit preauthorization message, including card information and the PIN, is sent to the switch and is preauthorized by either the switch or the cardholder DPC.

Allowable SHAZAM system transactions include, but are not limited to:

Cash withdrawal from a customer’s checking or savings account

Deposit to a customer’s checking or savings account

Cash advances from a credit card

Transfer of funds between a customer’s checking account and savings account

Transfer of funds from a customer’s credit card account to the customer’s checking account

Funds transfer credit and debit

POS payment from a customer’s checking account or savings account

POS payment with cash back

Bill payment

Pass-through inquiries of an account balance or a card withdrawal limit

Debit preauthorization request

Availability of the above transactions may be limited due to the physical characteristics of the terminal in use and banking regulations that prohibit certain types of transactions (e.g., interstate deposits) under certain conditions.


Page 32

Transaction Controls

Transactions are entered into terminals in a predefined format prior to the transaction’s submission. Transactions require a predefined keying sequence that cannot be deviated from when entering a transaction into the terminal. The sequence is completed before the communications controller device transmits the transaction to SHAZAM for processing.

Transactions are submitted to the switch in a predefined message format with identifiers for allowable transactions and contain the information required for completion. Messages include the encrypted cardholder PIN block, information read from the magnetic stripe on the back of the card, terminal information and the transaction request.

The switch processing system performs programmed edit tests that are designed to detect invalid and incomplete transaction data. These include:

Message length (in characters) validation

Transaction code validation

Transaction amount validation

Transaction balancing

Validation that the terminal number, originating DPC number, destination DPC number, terminal and system sequence numbers, and processing date agree in the transmission of a message for a transaction

Certain cardholder PINs verified by SHAZAM at the financial institution’s option

In addition, edit tests have been designed to check the prior transaction to help determine whether it has not been duplicated and has been completed.

The first segment of a PAN identifies the cardholder’s financial institution. Transactions are routed to the designated cardholder DPC based on this segment of the PAN. Through the use of a routing table, this number is converted to the corresponding ABA number. The ABA number is then matched against the bank control file to obtain the cardholder’s DPC.

With a SIF terminal, the terminal number is obtained through the station table, which identifies the terminal number based on the communication type and either the internet protocol (IP) address, PU (physical unit) address or poll code. With a SBH terminal, the terminal number is transmitted by the acquiring DPC. SBH terminal information is maintained in a consolidated terminal file.

Authorization responses are matched to the initial authorization request message. Transactions routed to cardholder DPCs receive an authorization response within a predefined time period originating from the corresponding communication channel.

Switch processing, other than settlement and the generation of settlement reports, is performed on the online system.

When a financial institution is added to the network, a processing agreement is authorized by the establishing financial institution and SHAZAM. In addition, when a terminal or DPC is added/deleted from the network—or when a financial institution makes a change to a terminal, financial institution or bank identification number (BIN) parameters, or the DPC parameter option—SHAZAM makes updates to the terminal, financial institution or BIN record. For these types of changes, the requesting financial institution submits a completed service agreement and certain other forms authorized by the financial institution and the settlement financial institution.

These changes are entered into a hold queue on the online system by SHAZAM implementation and support personnel upon receipt. The changes are approved by SHAZAM management at the daily production management meeting before the changes are added to the online computer system.


Page 33

Transaction routing is performed based on a segment of the personal account number (PAN) stored in the terminal control file and bank control file. Certain designated computer consoles submit jobs that modify the online system’s terminal control file and bank control file. Other computer consoles connected to the online system are restricted to displaying information. Current versions of data files reside on the online system. Transactions processed by the switch are logged to daily transaction files. At daily cutoff (6 p.m. CT), batch processes accumulate transaction activity based on an 18:00 prior day to 18:00 current day for funds movement between issuing and acquiring institutions and daily reporting. The daily funds movement settlement process determines whether total transaction debits equal total transaction credits. If the system is not in balance, computer operations personnel are responsible for resolving the problem with the assistance of programming and client support.

Merchant Transaction Processing

SHAZAM’s Merchant Services allows financial institutions and their participating merchants to obtain purchase and cash advance authorizations and perform electronic ticketing of Mastercard, Visa, American Express and Discover transactions. To be a SHAZAM Merchant Services participant, financial institutions are SHAZAM participants. SHAZAM has contracted with First Data of Omaha, Nebraska, to provide authorizations, settlement, reporting, billing and statements.

Allowable transactions include:

Authorization only—purchase

Authorization and electronic ticket capture—purchase

Force post (ticket only)—purchase

Authorization only—cash advance

Authorization and electronic ticket capture—cash advance

Force post (ticket only)—cash advance

Merchandise return

Transactions submitted to First Data may take two forms—authorization only or authorization and electronic ticket capture. An authorization-only transaction confirms a cardholder has sufficient available credit for a charge and reserves the authorized amount against the cardholder’s available balance. If a force-post transaction (which posts the transaction amount to the cardholder’s account) is not received by First Data within a specified number of days, the reserved balance is released for other transactions. An authorization and electronic ticket capture performs the verification and posts the amount in one transaction.

At a credit POS terminal, a merchant entering purchase information into the terminal initiates a transaction; this information is then routed to First Data for authorization.

The approval or denial response from First Data for authorization-only and authorization and electronic ticket capture transactions, are sent directly to the merchant point of sale equipment from First Data. This response represents either a denial message or an authorization code that either prints on a receipt or displays on the terminal.

Reports are generated by First Data and are delivered electronically to SHAZAM. Various First Data-generated reports are separated and delivered electronically by SHAZAM to participating financial institutions. SHAZAM participants are responsible for balancing these reports to their daily settlement.

Applicants participating in national bankcard programs are subject to a financial soundness evaluation based on predefined objective criteria. These evaluations are reviewed by the Safety and Soundness Committee, a committee of the board of directors, as part of the process for approval of participation.


Page 34

Participants are subject to evaluations by the Safety and Soundness Committee according to the same evaluation criteria. Based on direction from the Safety and Soundness Committee, management takes action when indicated by the evaluations.

DPC Stand-In Authorization

Data processing center (DPC) stand-in authorization occurs when a cardholder DPC is inoperative, the DPC communication link is out of service or the DPC has a slow response time to a switch processing transaction request. This is a required service for cardholder DPCs. When SHAZAM detects DPC stand-in authorization is needed, the online system authorizes or denies transaction requests based on predefined parameters established by the cardholder financial institution and the type of DPC stand-in authorization service elected by the financial institution.

There are multiple types of stand-in authorization service available:

Positive file stand-in authorization with PIN

PANs and the associated PIN verification values (PVVs) (if the bank identification number [BIN] supports customer-selected PINs) are stored in SHAZAM’s PAN database. If the PAN received from the EFT terminal matches an entry in this database and the PVV received from the EFT terminal matches the PVV on file (if customer-selected) or the PVV derived from data on the magnetic stripe, SHAZAM authorizes the transaction. Cardholder financial institutions may establish cardholder-level withdrawal limits for their customers. Under the basic service option, daily withdrawal limits are established. For the expanded service option, both daily and three-day withdrawal limits are established. With this option, issuers may provide a positive balance file, which is used to restrict authorization to an amount available in the cardholder’s account.

Positive file stand-in authorization without PIN

PANs are stored in SHAZAM’s PAN database. However, the associated PINs are not. If the PAN received from the terminal matches the entry in the database, SHAZAM authorizes the transaction. Financial institutions may establish withdrawal limits under the basic or expanded service options. With this option, issuers may provide a positive balance file, which is used to restrict authorization to an amount available in the cardholder’s account.

Positive file stand-in authorization with positive balance file (PBF)

Financial institutions and cardholder DPCs have the option to provide a PBF to SHAZAM for stand-in authorization with PBF.

Negative file stand-in authorization with PIN

Negative file is a listing of hot cards and warm cards denied access during DPC stand-in authorization. The financial institution will establish institution-level withdrawal limits for good cards that receive access during DPC stand-in authorization. The PVV from the terminal is verified against the PVV derived from information on the card’s magnetic stripe and the encryption key on file at SHAZAM. Transactions from cards that are not matched on the negative file are automatically approved and processed.

Negative file stand-in authorization without PIN

Negative file is a listing of hot cards and warm cards denied access during DPC stand-in authorization. The financial institution will establish institution-level withdrawal limits for good cards that receive access during DPC stand-in authorization. No PIN validation is performed.

The positive file and negative file stand-in authorization options without PIN are available during the DPC’s scheduled hours of operation.


Page 35

If a transaction is attempted with a card that has been identified as hot or warm (for example: lost, stolen or suspicious transactions) in the PAN database, it is rejected by the system. If the transaction is attempted using a hot card, the card may be captured and retained by the terminal (if the terminal is equipped to capture cards).

The PAN database and BIN table are used for DPC stand-in authorization. Transactions are processed in accordance with parameters established by the financial institution for the BIN and placed in a store-and-forward file. The PAN database contains financial institution information on its specific cardholders. This information varies according to the service level chosen by the financial institution and generally includes the PAN; PVV; card status indicator; daily withdrawal limit; daily withdrawal accumulator; three-day withdrawal limit; three-day withdrawal accumulator; savings, demand deposit account (DDA) and credit account numbers; savings, DDA and credit restriction codes; and the deposit percentage and maximum dollar limit available for immediate withdrawal. The card status indicator identifies the card as hot, warm or containing “no restriction” and is set to allow or reject savings or DDA account transactions.

If the positive file stand-in authorization service is used, the cardholder’s withdrawal accumulators in the PAN database are updated during the transaction. If the negative file stand-in authorization service is used, a new record is created within the PAN database the first time a card is used on a given day. This new record contains the PAN, the financial institution daily and three-day (if applicable) withdrawal limits as defined in the bank control file, the daily and three-day (if applicable) withdrawal accumulators and a “no restrictions” code in the status field. When a card is used, the cardholder card number database is searched. If the system finds a record, the withdrawal accumulator fields are updated. There is no limit on the number of transactions authorized during DPC stand-in authorization.

Financial institutions update information in the PAN database via online maintenance through the processor interface, data entry through SHAZAM Access or a batch file transmission through SHAZAM Access using secure file transfer protocol (FTP).

SHAZAM accepts telephone calls to manually flag hot or warm cards. Additionally, SHAZAM has established an interactive voice response (IVR) system to flag hot or warm cards.

A store-and-forward file is used to log transactions authorized by SHAZAM during DPC stand-in authorization. Transactions are automatically sent to the DPC when communication with the DPC is re-established. A financial advice (a stand-in authorized transaction) is sent to the cardholder DPC for posting, and the cardholder DPC sends an acknowledgement to SHAZAM after receiving the advice.

If proper acknowledgment is not received within a specific time frame, the item is retransmitted based on DPC settings (up to seven retransmissions) before clearing and transmitting the next item.

To prevent the duplication of a financial advice, a flag is set on a transaction after it has been successfully transmitted. Since no control totals or counts are accumulated in the store-and-forward file, the DPC receives just transaction details in this transmission. In addition, since transactions received in the transmission have been previously authorized on the DPC’s behalf, transactions are posted by the DPC upon receipt.

If communication with the DPC is interrupted while store-and-forward transactions are being transmitted, SHAZAM stops transmission and resumes transmission when communication is restored. A store-and-forward transaction may be retransmitted by SHAZAM if transmission is interrupted.


Page 36

Card Authorization Services

Through the card authorization services (CAS) system, SHAZAM allows financial institutions that are not associated with one of the member DPCs to participate in the EFT system. Transactions are authorized at SHAZAM through reference to parameters established by the financial institutions regarding transaction limits and other processing restrictions. Transactions are evaluated for authorizations based on parameters specified in the bank control file database and cardholder data documented in the card database.

There are two authorization service levels under the CAS system:

Basic—The basic level offers electronic transmission for delivery of SHAZAM-authorized transactions between the financial institution and SHAZAM. PANs have a daily withdrawal limit, cash withdrawal limit, three-day withdrawal limit and account type restrictions as established by the financial institution.

Account balance—The account balance level offers electronic transmission for delivery of SHAZAM-authorized transactions between the financial institution and SHAZAM. A financial institution may set daily withdrawal limits, cash withdrawal limits, three-day withdrawal limits, supported accounts and transaction restrictions for a PAN. In addition, the financial institution individually limits the amount of deposits available for immediate withdrawal by establishing an immediate withdrawal percentage that is used by SHAZAM to calculate the available amount. The financial institution may also make electronic inquiries via SHAZAM Access regarding cardholders’ card numbers and account balances held on file. Cardholders may inquire about their checking and savings account balances via ATM.

Transactions are received in a predefined format that contains cardholder identifiers and required information, such as a PIN, to complete the transaction. The transactions are authenticated using these cardholder identifiers. Invalid transactions are denied. Transactions are routed to CAS for processing based on a segment of the PAN. Transaction messages include the PAN and an encrypted PIN block. Upon receipt of a transaction, the CAS system matches the PAN in the message received to an entry in the card database and confirms the PVV, if present. Transactions with an unmatched PAN or invalid PIN are rejected. The CAS system also rejects the transaction if the card is identified as listed on the negative file (for example: a lost or stolen card). Transactions are evaluated for authorization based on parameters specified in the BIN database and cardholder data documented in the card database. The card database is automatically updated for authorized transactions. Authorized and unauthorized transactions are reported on the cardholder institution settlement report. Authorization responses are automatically matched and recorded to the initial authorization request message. Response codes indicating success or failure are reported on the resulting settlement report.

Once a transaction is approved or rejected, the transaction is written to a transaction database, and information from transactions having a financial impact (for example: ATM withdrawals, POS purchases or SHAZAM®Chek completions) is written to a posting item database. The posting item database is replicated to an offline database for posting file creation by a back-office process.

Posting files are created daily by the back-office system by creating ACH-formatted header, trailer and detail records from the replicated data. The batches are made available for delivery to the institutions electronically via the SHAZAM Access Files tab or through the federal ACH receipt system. Those receiving posting files via SHAZAM Access may elect to receive a second posting file (created at 7 a.m. CT) in addition to the afternoon posting file.

CAS users with one or more SHAZAMChek BINs may elect to receive a file of SHAZAMChek authorizations for which the completion has not been received. These are known as outstanding authorizations. The financial institutions use the file to adjust their cardholders’ available funds for internal and over-the-counter use.


Page 37

Transactions are logged to the RTA log on ALCS. The RTA log is auto-balanced daily to confirm that total debits per the log equal total credits. The RTA log is used to recover data in the unlikely event of data loss or corruption of the CAS transaction database.

The electronic transmission of data is initiated at the request of the financial institution via the SHAZAM Access Files tab following login using the financial institution username and password procedure.

Modifications to the card database are authenticated through a secured file transfer system, or the SHAZAM Access Files tab which utilizes transport layer security (TLS) encryption.

Electronic transmissions created by SHAZAM include trailer records that contain transaction control totals. CAS financial institutions are responsible for validating these totals to the reports of the transaction data they receive.

ACH Receive

ACH items and the applicable routing information are received by SHAZAM from the FRB through electronic transmission using the FRB’s computer interface connection. This transmission is received in an encrypted format over a dedicated, leased telephone line. It is a Transmission Control Protocol/IP connection using Cisco® hardware. The FRB owns and supports the hardware, and the hardware is connected to the FRB with redundant 56K frame-relay circuits. The FRB’s equipment is connected to third-party purchased software (Connect:Direct® with Secure+) via redundant IP connections.

The sums of debits, credits and number of items transmitted are automatically reconciled to a trailer record included in the data transmission from the FRB. Out-of-balance conditions noted are flagged for follow-up. Information received from the FRB’s pending transmission to financial institutions, and information received from financial institutions’ pending transmission to the FRB, is written to a staging file on the offline system. The information is automatically totaled and compared to control totals included in a trailer record of the transmission. Differences identified during this comparison are flagged by the system and resolved by computer operations personnel prior to processing.

Following the validation of the ACH transmission from the FRB, the data in the staging file is sorted by ABA number and separate files are created for the participating financial institutions. These separate files are then written to a sequential transmission file to await transmission to the financial institutions.

The data is transmitted to the financial institutions via SHAZAM Access (Xythos), SFTP or NDM. The SHAZAM Access software permits financial institutions to initiate transmissions by connecting to the system and providing the system with a username and password. As part of the transmission process, the software confirms the transmission is complete. Downloads by the financial institution are authenticated through a secure FTP system. Files created for download contain control totals to validate transmission completeness.

ACH Origination

With SHAZAM ACH, the user originates different types of ACH files, such as:

Direct deposit

Direct payment

Government transactions (state and federal tax payments and child support)

Vendor payments

ACH returns/notifications of change for financial institutions


Page 38

Corporate customers may use SHAZAM ACH in case they have daily ACH activity or late processing. Many member institutions use SHAZAM ACH to originate notifications of change and returns, along with loan payments and the processing of files for other companies.

SHAZAM ACH uses a secure, Web-based interface that allows the user to originate different types of ACH files using Internet access. The files are transmitted to SHAZAM and uploaded four times per day from a distributed server to the offline system for formatting verification. Information received from the FRB, which includes pending transmissions to financial institutions, and information received from financial institutions, which includes pending transmissions to the FRB, are written to secure staging files. Files are sent to the Goldleaf warehousing system, then to the FRB using NDM.

Files created, stored and transmitted by the software are encrypted at the user level by the application. Communication between the Web server and client’s browser is encrypted with a TLS certificate from Symantec.

SHAZAM’s ACH system security uses multifactor authentication using IBM’s ISIM and ISAM platforms. ISIM provides access management and enforces user’s roles and privileges. ISAM provides identity management to provide updates to user profiles and privilege attributes. Using ISIM/ISAM, users are provisioned into SHAZAM ACH. Once provisioned, users are required to enter a static password and a one-time password delivered via SMS to authenticate and gain access. SHAZAM uses the Goldleaf warehousing application in support of SHAZAM ACH. This application pulls files from the directory and imports them into the data warehouse. The warehouse pulls batches with an effective date of the next business day or earlier to send to the Federal Reserve.

Items conform to the required format described in NACHA’s ACH Rules Book. The information received from the financial institution or corporate originator is written to an offline system, and the ACH items are totaled for comparison to control totals included in a trailer record of the transmission from the FRB to validate its content is complete. Additional edit tests are performed to help determine whether the ACH items submitted designate the financial institution as the originating depository financial institution (ODFI). Transmissions from the financial institutions occur using password-protected transmission software. The sums of debits, credits and number of items transmitted are automatically reconciled to control totals from the ODFIs. Differences identified during this comparison are flagged by the system and resolved by production support personnel prior to processing.

After validation of the ACH transmission, the data in the staging file is written to a sequential transmission file to await transmission to the FRB using NDM. Operations personnel are on staff 24/7 to monitor transmissions.

PIN Processing

PINs are used to provide authentication when a cardholder performs a transaction at an ATM or merchant POS terminal (with the exclusion of credit card authorization transactions).

Authentication is established when the PIN is entered by the cardholder. Following its encryption at the PIN-entry device, the PIN is combined with the card number to form the PIN block. It is then sent to SHAZAM where it is either compared to the PIN stored at the cardholder data processing center (DPC) or validated through the Card Authorization Service (CAS) system. To help determine whether PINs are protected from unauthorized disclosure during transactions, the PIN block is encrypted during transmission to and from SHAZAM using the triple data encryption standard (3DES) algorithm. Cardholder PINs are decrypted within special tamper-resistant security module (TRSM) encryption devices within the host security module (HSM) and are not transmitted from the HSM in an unencrypted format. Controls within the HSM prevent PINs from being accessed while they’re decrypted.

Terminals encrypt the cardholder PIN upon entry into the encrypting PIN pad (EPP) using the terminal’s PIN encryption key. This key is generated daily from SHAZAM’s local master key and is transmitted to the terminal after being encrypted under the terminal master key.


Page 39

Switch processing occurs as follows: 1) SHAZAM references the terminal ID in the terminal control file to confirm the validity of the terminal; 2) the HSM matches the terminal master key and the PIN encrypting key and decrypts the PIN. The HSM then either encrypts the PIN under a shared DPC exchange key for transmission to the corresponding DPC or obtains the encrypted cardholder PIN from the CAS system and the cardholder financial institution’s PIN verification key. SHAZAM forwards these items to the HSM that makes a PIN comparison. If the PINs match, the HSM sends an “authorized” message to conduct the transaction. Decryption, regeneration and comparison of PINs occurs within dedicated hardware devices. Keys are not stored in clear text from outside the HSM. The HSM is housed within a specially segmented and physically secured computer room that is monitored. Additionally, the HSM is designed to erase its contents in the event that it senses tampering. Physical access to the secured data center where TRSMs and HSMs reside is reviewed and authorized by management annually.

Key Management

Encryption Keys

There are three basic uses of encryption keys at SHAZAM:

Master keys that encrypt other keys (master file keys and local master keys)

Keys that encrypt other keys for transmission across networks (key exchange keys and zone control master keys)

Keys that encrypt PINs for transmission (working keys, communication keys, transaction keys and session keys)

SHAZAM’s relationship as a financial institution processor with direct connections to Visa, Mastercard and other regional processing networks requires that SHAZAM undergo PIN security and key management reviews to confirm that industry practices are followed.

Encryption Key Life Cycle

Encryption keys have a defined life cycle. Keys are created, stored, transported, distributed, loaded and destroyed. SHAZAM follows industry practices for managing the phases of this cycle.

Creating Encryption Keys

Manual creation of encryption keys requires at least two key custodians to enforce the concept of split knowledge and dual control. Custodians are responsible for generating one clear-text component that is used to form the encryption key. Key generation uses a process that is random, which makes a key unpredictable. SHAZAM uses an HSM to generate key components. At least two components are required to create a key.

SHAZAM’s procedures require that at least two key custodians interface with the HSM to create separate components and their corresponding check-digit value. This dual-control/split-knowledge requirement counteracts the possibility of one individual knowing the entire key value (i.e., would require collusion). The key-check value is a redundancy check used for error detection.

Access to the HSM is physically and logically controlled to limit direct physical access to those authorized key custodians who are allowed to create encryption key components. The names and specific key management responsibilities of key custodians are maintained through central documentation, and key custodians attest annually to their understanding of expected behaviors in the management of cryptographic keys.


Page 40

Settlement

Transactions are authorized by SHAZAM, other network hosts, processors, Visa, Mastercard and First Data and accumulated in accounts for settlement. Participants in the settlement cycle include financial institutions, merchants and networks. Settlement of the transactions that flow through the networks and accounts are included with the daily settlement between SHAZAM and those participants.

For debit settlement, an automated balancing procedure compares total debits to total credits, and control totals generated from the RTA log compare to control totals generated from the terminal control file and bank control file. Out-of-balance conditions result in an ISR being opened to inform the EFT implementations department of the issue, where it is then reviewed and corrected. The switch processing system accumulates and maintains running balances of transactions processed by the foreign networks and the financial institutions. SHAZAM computes the amounts needed to settle these transactions between the foreign networks and the financial institutions and then reports this information to the financial institutions along with transaction information daily. SHAZAM also generates transactions to settle these amounts through the Federal Reserve’s ACH system.

During settlement, SHAZAM:

Totals debits and credits for participating financial institutions

Creates a net position for participating financial institutions

Creates an ACH or wire item

Routes the item to participating financial institutions’ designated settlement accounts

As part of the settlement process, SHAZAM creates a file by settlement financial institution ABA number that contains the individual net settlement dollar amounts in ACH format. This file is encrypted and transmitted electronically to the Federal Reserve over its dedicated leased line.

For credit settlement, SHAZAM uses a third party, First Data, to process transactions. For electronic activity, First Data initiates an ACH on SHAZAM’s bank account through the Federal Reserve’s ACH system to debit or credit the merchant accounts for their net settlement. First Data wires funds from the cardholder's financial institution to SHAZAM for the net settlement amounts.

The finance department within SHAZAM is responsible for reconciling SHAZAM’s settlement accounts by balancing the sum of the internal and external detail to SHAZAM’s bank account. Reconciliations are performed for both credit and debit services.

Modifications to the bank control file are documented and assigned to the client implementation services group responsible for bank control file changes. Changes are approved by a manager prior to implementation. Modifications to the PAN and bank control file online databases are authenticated through a secured file transfer system. Modifications that are needed or requested to the financial institutions’ online databases are documented and assigned to the SHAZAM production support group for implementation. Changes are approved by management.

Switch Usage Billing

SHAZAM’s automated billing system captures switch billing items as they occur during the month. These billable items are summarized on a nightly basis, with reports created for the month-to-date details by client and billable item. SHAZAM’s billing system includes items such as transactions, authorization fees, product and network participation fees, maintenance, file residency and reporting.

The month-end billing process is cut off at 6:00 p.m. Central Time on the last day of the month. Billing statements are created and placed in SHAZAM Access for clients to electronically download and are collected via ACH on the sixth business day of the following month. SHAZAM has documented procedures to assist billing personnel in the performance of their duties.


Page 41

Billing terms related to switch usage are standard. SHAZAM maintains standard fee schedules for switch usage billing. The implementation team sets up new financial institutions, who are billed based on what is established in the fee schedule. In special circumstances, different billing terms than the standard agreement can be configured based on client request. In order to verify the billing terms are consistent with the rates agreed-upon with the client, a senior member of SHAZAM management must review and acknowledge the terms prior to activating the client in the system.

The majority of the billing items are generated automatically based on transactions/activity occurring on the network, client settings and operational settings for terminals. Automatic switch settlement occurs daily on the mainframe (offline) system. Finance is automatically notified of potential out-of-balance settlement conditions. The finance department is responsible for reconciling settlement accounts by balancing the sum of the internal and external detail to SHAZAM’s bank account within a settlement spreadsheet on a daily basis.

There is a subset of items that are manually entered into billing by the finance department. These items include customer adjustments and billing items that have not been automated on the billing system. Billing items not automatically billed by the system include adjustments of monthly and one-time terminal and processor fees, collection of applicable sales tax, collection of deconversion fees, special pricing credits, sales of publications and other miscellaneous items. Portions of these items are manually keyed into the system by finance, and others are handled through uploads by the IT area. Finance maintains hard-copy documentation for manual billing items entered. After manual billing items are entered, a report is run listing the manual billing items, and the items are then reviewed by finance personnel for accuracy. Financial institutions are provided settlement information reports daily, which are automatically posted to the SHAZAM Access repository.

On a monthly basis, the mainframe will automatically generate switch usage bills. The finance department performs a monthly review of the billing system for completeness and accuracy. Staff members will review the billing calculations to validate the amounts. This review process includes a comparison of billing data completed prior to the release of customer statements. Monthly billing data is reviewed in comparison to the prior month’s data, including dollar amounts and transaction counts. Once billing data has been reviewed for the month, and any identified discrepancies resolved, the review is considered complete for the month and is signed off.

Client billing disputes and adjustments are submitted via an internal paper adjustment form and typically originate in the client support or sales team areas. The adjustment form must be completed and signed by various levels of management based on the dollar amount, including the department manager, the accounting manager, the controller and, in some cases, the department’s vice president. The adjustments are entered into the system by finance upon receipt of required approval.

There are numerous activities to perform and charges to apply an adjustment or credit, including tax calculations, pass-through interface fees, pricing incentives, training fees and other non-automated billing items. In order to ensure these activities have been performed, a checklist is utilized, listing the activities for financial staff members, which is reviewed and signed off by the billing analyst when complete.

Chargebacks and Disputed Items

SHAZAM chargeback specialists are provided applicable Visa and Mastercard documentation as reference in order to comply with chargeback and representment requirements. Incoming exception item information from Mastercard and Visa signature-based issuers is automatically entered into a tracking system in order to monitor the progress of exceptions toward resolution.

Merchant Chargebacks

First Data reports are reviewed daily to identify incoming merchant chargebacks, which are originated by the financial institution representing the cardholder (issuer). The issuer reviews the dispute (either a cardholder-initiated dispute or a financial institution-initiated dispute) as applicable to Mastercard, Visa or Discover regulations, and issues a chargeback.


Page 42

This chargeback flows from Mastercard, Visa or Discover to First Data and then to SHAZAM, which performs chargeback processing for the acquirer/merchant. At this point, the issuer is credited and the acquirer/merchant is debited for the chargeback. First Data sends notification of the chargeback to the acquirer/merchant for Mastercard and Visa disputes and SHAZAM sends notification of the chargeback for Discover disputes.

Chargeback personnel at SHAZAM review First Data reports, incoming chargeback information and additional information that may be supplied by the merchant to either accept the chargeback or issue a representment to the issuer (for example: the chargeback is reversed). If a representment is initiated, the chargeback funds flow back to the issuer and the acquirer/merchant is credited for the chargeback. SHAZAM chargeback personnel track incoming chargebacks until resolution. The finance department reconciles the chargeback items to settlement amount differences, and finance personnel monitor pending chargebacks and apply potential liabilities to a suspense account on a monthly basis.

Debit Chargebacks—Signature-Based

Outgoing debit chargebacks are processed by SHAZAM on behalf of SHAZAM debit card issuers. The SHAZAM financial institution representing the cardholder initiates a dispute by submitting an electronic Exception Item Request form and attaching applicable supporting documentation (for example: cardholder letters or receipts) via SHAZAM Access > Transaction History. SHAZAM’s debit chargeback personnel review this information and decide whether to charge back the disputed item according to applicable Mastercard or Visa regulations, order a copy of the ticket, request additional information from the financial institution or reject the request if chargeback rights do not exist. “No Recourse” and “Need Additional Information” notifications are emailed to the issuer. If a chargeback is initiated, the SHAZAM issuing financial institution is credited for the chargeback on their SSR114, Settlement Exception Activity report.

Chargeback personnel review and monitor settlement reports from Mastercard and Visa for incoming representment activity for debit cardholders on a daily basis. Representments automatically settle to the issuing financial institution. Visa debit chargeback personnel monitor system-generated reports to determine whether representments are being closed. The chargeback manager is notified automatically via an internal service request (ISR) when incoming representments are still open for Visa debit cardholders after 35 days. Debit chargeback personnel forward representment documentation to the issuing financial institution via email. The issuing financial institution will either accept the representment or may request chargeback personnel initiate a second chargeback (Mastercard only) or a pre-arbitration attempt (Visa only) to the acquirer.

Settlement of Mastercard second chargebacks appear on their SSR114. If a Visa pre-arbitration attempt is initiated, accepted and funds are received from the acquirer, credit appears on their SSR114 and the SHAZAM issuing financial institution is notified via email. If a Visa pre-arbitration attempt is declined, SHAZAM emails notification to the issuer. Finance reconciles Mastercard and Visa exception item activity on a monthly basis between the FDR system and the offline SHAZAM system.

Fraud Operations

SHAZAM has a designated fraud department staffed with associates with defined position descriptions. SHAZAM offers FICO Falcon Fraud Manager, a neural network technology that identifies fraud risk by detecting potentially fraudulent PIN- and signature-based debit transactions. SHAZAM offers both batch and real-time scoring. Real-time scoring allows fraudulent transactions to be denied during the authorization process before the issuer incurs liability. Debit card transactions flow through Falcon and are automatically assigned a score based on the level of risk associated with the transactions on the account. If the transaction(s) are assigned a risk score over a predetermined threshold, the system automatically creates a “case” to be reviewed by SHAZAM fraud operations specialists.


Page 43

When new rules are needed within Falcon for real-time scoring, a rules analyst will write and test the rule prior to it being placed it into production. SHAZAM also offers a 24/7 case management service to help monitor suspicious activity and manage fraud cases. If the transactions are assigned a risk score over a predetermined threshold or meet specialized rule criteria, the system creates a case to be reviewed by the SHAZAM fraud operations team. In most situations, Falcon cases are created based on scores assigned to the transactions by Falcon.

SHAZAM has established a minimum threshold score that is applied to financial institutions when they sign up for SHAZAM’s case management service. Prospective national bankcard participants are evaluated for financial soundness. This evaluation is presented during monthly meetings to a committee of the board of directors for approval of participation. Active national bankcard participants are evaluated for financial soundness. This evaluation is presented during monthly meetings to a committee of the board of directors for approval of participation. Exceptions to score-based case creation are noted below.

The cases created are assigned to queues that are prioritized based on the level of risk associated with transactions on the accounts. SHAZAM fraud operations specialists work through the cases that populate the queues daily in priority order to verify that those with the highest risk are worked first. SHAZAM has documented procedures to assist fraud operations staff in the performance of their duties. When a fraud specialist works a case, the specialist attempts to contact the cardholder via the telephone numbers supplied to SHAZAM by the financial institution.

Depending on the outcome of the call attempt, the specialist takes one or more of the following actions on the account:

Place a temporary card block (TCB) on the account.

Temporary card blocks are placed on accounts that have transaction activity with elevated risk scores in instances where the specialist is unable to contact the cardholder or the case is created outside of the normal calling hours of 8:00 a.m.–9:00 p.m. CT.

Call attempts are made using phone numbers supplied by the financial institution before the account is rescheduled for a follow-up attempt. Cases that are set to an active status and are re-queued for a call back are based on risk.

Cases receive at least two call-back attempts to reach the cardholder. If two call attempts are made and SHAZAM fraud operations cannot reach the cardholder, the case is closed as “Unable to Confirm.”

Place the account in a “hot-card” status.

This status irreversibly closes the account when fraudulent activity has been verified.

When this is done, the cardholder is instructed to contact his or her financial institution as soon as possible to go over the account activity in greater detail and have a replacement card issued.

This action closes the case out of Falcon.

Close the case out of Falcon as “Unable to Confirm.”

Cases falling into this category include:

- Those that have had two call attempts and meet TCB criteria

- Those that have had two call attempts and do not meet TCB criteria

- Those that have incorrect or nonworking telephone numbers

- Those created for informational purposes for the financial institution


Page 44

The financial institution is sent an email when a Falcon case is worked by SHAZAM fraud operations. Financial institutions are provided FD150R reports summarizing work performed by fraud operations if transactions were identified in Falcon for their institution. The financial institution may try to reach the cardholder after receiving the email from fraud operations. The financial institution may also request that the TCB or Falcon case be closed either by responding to the email or calling fraud operations directly. Financial institutions are provided a reports summarizing work performed by fraud operations. SHAZAM has documented procedures to assist fraud operations staff in the performance of their duties.

Report Generation and Distribution

After the network daily cutoff time, SHAZAM generates various activity and exception reports from the switch-logged transactions for terminal and cardholder transactions. These reports are automatically uploaded and can be retrieved electronically by the financial institutions and DPCs through the SHAZAM Access web portal. Defined user roles control access permissions within the SHAZAM Access web portal.

SHAZAM Access requires users to be authenticated in order to access their institution’s report repository. Financial institutions and DPCs are assigned a user ID, password and a defined user role to facilitate authentication to the SHAZAM Access portal. Access to the SHAZAM Access portal is through a secure TLS connection. Financial institutions have individual areas on the SHAZAM Access web portal to view and retrieve reports. A financial institution’s ABA number or a DPC’s number is used as the destination for report distribution.

Key Reports

Information Used in the Execution of a Control

System-generated reports are utilized in the execution of controls in Section IV. The table below summarizes the key characteristics of these reports used in the execution of these controls:

Report Name Control Number Report Purpose Source System Report Use

NetBatch Report 4.1 Report is generated on a daily basis by operations to review system processing the day prior. The report lists all the jobs ran on the specified day within the HP environment.

HP system

SHAZAM, Inc. is unable to modify the report code as this system is purchased from the vendor.

Execution of a control by the service organization

Zeke Report 4.1 Report is generated on a daily basis by operations to review system processing the day prior. The report lists all the jobs ran on the specified day within the IBM environment.

IBM AS400 OS / iSeries



Master Doors Report

6.1, 6.5 Report lists all the users who have access to the West Des Moines and Johnston SHAZAM facilities, including the on-site data centers at both locations. The report is used by SHAZAM as part of their annual physical access review.

Velocity




Page 45


RACF Access Listing

7.15, 8.8, 9.4

Report lists all the users who have access to the IBM production environment, including their access levels. This report is used by SHAZAM as part of their annual logical access review.

IBM (RACF)



HP Access Listing 7.15, 8.8, 9.4

Report lists all the users who have access to the HP production environment, including their access levels. This report is used by SHAZAM as part of their annual logical access review.

HP (Safeguard)



IDS Access Listing 7.15, 8.8 Report lists all the users who have access to IBM source code, including their access levels. This report is used by SHAZAM as part of their annual logical access review.

IDS



GIT Access Listing 7.15, 8.8 Report lists all the users who have access to HP source code, including their access levels. This report is used by SHAZAM as part of their annual logical access review.

GIT



Active Directory Access Listing

7.15, 8.8, 9.4

Report lists all the users who have access to the SHAZAM network, including their access levels. This report is used by SHAZAM as part of their annual logical access review.

Active Directory



SHAZAM ACH Listing

7.15, 8.8, 9.4

Report lists all internal users who have access to SHAZAM ACH, including their access levels. This report is used by SHAZAM as part of their annual logical access review.

SHAZAM ACH

SHAZAM, Inc. can modify the report code and is responsible for the completeness and accuracy of the report.


SHAZAM Access Listing

7.15, 8.8, 9.4

Report lists all internal users who have access to the SHAZAM access application, including their access levels. This report is used by SHAZAM as part of their annual logical access review.

SHAZAM Access



Origination Load Report

10.3 The report is used by SHAZAM personnel to review ACH data, how many files were input and the details on the transactions prior to sending data to the FRB.

IBM and Goldleaf




Page 46


ACH Origination File Report

10.3 The report is used by SHAZAM personnel to confirm that ACH data sent to the FRB was accepted and values match SHAZAM ACH values.

Federal Reserve Bank


Execution of a control by the service organization.

Debit Settlement 14.2, 16.4

Report is used by the finance department to verify that settlement and debit transactions are reflected completely and accurately.

HP and IBM



Miscellaneous Billing Checklist

15.4 Reports are used while invoicing occurs, and finance will review the billing calculations on a per-client basis to validate that the amounts are complete and accurate.

HP & IBM



Chargeback Suspense Reconciliation

16.5 Reports are used while invoicing occurs, and finance will review the chargebacks on a per-client basis to validate that the amounts are complete and accurate.

HP and IBM



Information Prepared for User Entities

The table below captures key reports generated from the systems for use by user entities:

Key Report Name Relevant to

Control Number Report Purpose System of Origin

Settlement Report 10.1, 10.2, 12.4, 12.6, 14.3, 18.2

The report details the past days’ activity that has been processed by SHAZAM for the applicable FI, including any successful or denied transactions.

(Report is inclusive of SSR 114 report)

HP, DB2 and SHAZAM Access


FD150R Report 17.5 The report details the past days’ activity that has been processed through SHAZAM's fraud monitoring department for the applicable FI, including any cases worked or still within Falcon (fraud monitoring tool).

Falcon and SHAZAM Access


Complementary Subservice Organization Controls

SHAZAM, Inc. uses First Data Resources to perform authorizations, settlement, reporting, billing and statements for merchant transaction processing in support of the delivery of EFT services. The scope of this report does not include the controls and related control objectives at the subservice organization. Management monitors the subservice organization’s controls through regular communication regarding service levels and annual review of their SOC report and complementary user entity controls.


Page 47

Below are the applicable control objectives that are impacted by the subservice organizations and the controls expected to be implemented at the subservice organizations to meet the applicable control objectives:

Subservice Organization

Applicable Control Objective Controls Expected to be Implemented to

Meet Applicable Control Objectives

First Data Resources

Control Objective 12: Controls provide reasonable assurance that transactions processed through Data Processing Centers (DPCs) and Card Authorization Services (CAS) are secure and authorized.

Automated system controls are in place to provide reasonable assurance the data for sales is completely and accurately reflected in generated transaction and settlement reports.


Control Objective 14: Controls provide reasonable assurance that the system is in balance prior to settlement and net settlement amounts are computed completely and accurately.

Automated system controls are in place to provide reasonable assurance the data for sales is completely and accurately reflected in generated transaction and settlement reports.

Responsible for the complete and accurate reporting of remittance amounts provided for cardholder bank accounts

Responsible for the complete and accurate reporting of batch and transaction submissions.


Control Objective 16: Controls provide reasonable assurance that debit chargebacks or unsatisfactory settlements are monitored for timely resolution, and are based on written procedures that coincide with applicable network rules.

Responsible for providing complete and accurate financial statements and supporting documentation of funding and chargeback postings.

Complementary User Entity Controls

SHAZAM’s processing of transactions, and the controls over the processing, were designed with the assumption that certain controls would be placed in operation by user entities. This section describes some of the controls that should be in operation at user entities to complement the controls at SHAZAM. User auditors should determine whether user entities have established controls to provide reasonable assurance that the following controls are in place:

Switch Processing

Financial institutions are responsible for authorizing changes to the PAN prior to sending a change request to SHAZAM. (Control Objective 11)

ACH

Financial institutions that use the SHAZAM ACH origination service are responsible for certifying that the access is restricted to authorized and appropriate users and that dual control and separation of duties are implemented. (Control Objective 7)

Financial institutions that use the ACH Receive service are responsible for reconciling the ACH items transmitted from SHAZAM to the totals in the trailer record transmitted and the totals in their Federal Reserve Bank statements. (Control Objective 10)


Page 48

Card Authorization Services

CAS users receiving transactions electronically, which had been approved by the CAS system, are responsible for validating that the transaction totals correspond to the batch totals in the trailer record. (Control Objective 10)

CAS users are responsible for reviewing transaction listings from electronic transfers to trailer records and daily reports to verify transactions have been processed completely and accurately. (Control Objective 10)

CAS users are responsible for reviewing the response codes of transactions reported on the Settlement Report to verify transactions have been processed completely and accurately. (Control Objective 12).

Chargeback

Financial institutions are responsible for monitoring chargeback requests using the Chargeback Activity (JCD020) report. (Control Objective 16)

Merchant Processing

Merchant transaction processing participants are responsible for balancing the reports received from SHAZAM to their daily settlements and verifying the accuracy of transactions submitted to First Data via SHAZAM. (Control Objective 14)

SHAZAM Access

Financial institutions that use the SHAZAM Access web portal for report/data transmission are responsible for establishing security administration user accounts that provision user access. (Control Objective 7)

Participating financial institutions are responsible for reviewing exception reports to identify the cause of exceptions and verifying that transactions have been processed completely and accurately. (Control Objective 10)

Participating financial institutions are responsible for performing balancing procedures to verify that the applicable daily reports, settlement reports, ATM logs and settlement cash account statements are in agreement. (Control Objective 14)

Financial institutions are responsible for safeguarding their SHAZAM Access and SHAZAM ACH usernames and passwords and notifying SHAZAM if they suspect an account has been compromised. (Control Objective 7)

Participating financial institutions are responsible for reviewing activity that has been processed through SHAZAM's Falcon fraud monitoring tool including any cases worked or still within Falcon to verify the transaction activity that was flagged as fraudulent within the FD150 report. (Control Objective 17).

SHAZAM, INC. SHAZAM, INC.’S CONTROL OBJECTIVES AND RELATED CONTROLS AND RSM US LLP’S TESTS OF CONTROLS AND RESULTS OF TESTS

Page 49

IV. SHAZAM, Inc.’s Control Objectives and Related Controls and RSM US LLP’s Tests of Controls and Results of Tests

SHAZAM, Inc.’s control objectives and related controls are an integral part of management’s description and are included in this section for presentation purposes. RSM US LLP included the description of the tests performed to determine whether the controls were operating with sufficient effectiveness to achieve the specified control objectives and the results of tests of controls, as specified below.

Tests of the control environment, risk assessment, information and communication, and monitoring included inquiry of appropriate management, supervisory and staff personnel, observation of SHAZAM, Inc.’s activities and operations, and inspection of SHAZAM, Inc. documents and records. The results of those tests were considered in planning the nature, timing and extent of RSM US LLP’s testing of the controls designed to achieve control objectives. As inquiries were performed for substantially all of SHAZAM, Inc.’s controls, and testing of the completeness and accuracy of information produced for populations was utilized for control testing, these tests were not listed individually for every control in the tables below.

Organization and Administration Controls

Control Objective 1: Controls provide reasonable assurance that management and the board of directors provide oversight and monitoring of financial performance and risk management.

Provided by SHAZAM, Inc.

Procedures Performed by RSM US LLP

Control Test Performed Test Results

SHAZAM is governed by the SHAZAM board of directors that meets on a semiannual basis and is responsible for oversight and monitoring of performance. The board represents insured depository financial institutions, state financial institution regulators in Iowa and financial institution trade associations.

Inspected a list of the SHAZAM board of directors to determine whether general composition, representations and qualifications were defined.

No exceptions noted.

Inspected a description of the responsibilities of the SHAZAM board of directors to determine whether responsibilities were documented.


Inspected board meeting minutes for a sample of semiannual meetings to determine whether the board met and monitored performance.


Management plans and budgets on an annual basis.

Inspected the annual budget to determine whether management planned and budgeted on an annual basis.


Personnel policies and procedures are documented in the employee handbook and employees sign a document indicating that they understand the contents of the employee handbook.

Inspected the employee handbook to determine whether policies and procedures were documented.


Inspected employee handbook acknowledgement forms for a sample of new hires to determine whether employees acknowledged understanding of the contents contained in the employee handbook.



Page 50

Control Objective 1: Controls provide reasonable assurance that management and the board of directors provide oversight and monitoring of financial performance and risk management.




Management completes background screening on prospective employees prior to employment including:

Criminal background checks

Verification of previous employment

Verification of stated education

Social Security number

Banking sanctions list

Inspected background checks for a sample of new hires to determine whether background checks were performed prior to employment including:

Criminal background checks

Verification of previous employment

Verification of stated education

Social Security number

Banking sanctions list


Employees sign a document annually indicating that they receive and comply with SHAZAM’s security and privacy policies.

Inspected electronically signed security and privacy policies for a sample of current employees to determine whether they acknowledged receipt and compliance with SHAZAM’s security and privacy policies.


SHAZAM develops an internal audit plan annually to identify and monitor the various levels of risk within the organization.

Inspected the annual internal audit schedule to determine whether a detailed plan for internal audit reviews was developed and documented.



Page 51

Control Objective 2: Controls provide reasonable assurance that the organizational structure has been documented to provide segregation of functions within operational departments.




Job descriptions are maintained that contain specific job responsibilities to support segregation of functions, and are reviewed by management when significant changes in duties or responsibilities occur.

Inspected job descriptions for a sample of positions to determine whether the descriptions documented specific job responsibilities to support segregation of duties.


Inspected job descriptions for a sample of positions that had significant changes in duties or responsibilities to determine whether they were reviewed and approved by management.

No tests of operating effectiveness occurred as the circumstances that warrant the operation of the control did not occur during the report period; there were no significant changes to job duties or responsibilities.

Positions have been defined within SHAZAM’s organizational structure, which define reporting relationships to support segregation of duties.

Inspected an organization chart to determine whether separate department reporting relationships were defined.



Page 52

Computer Operations Controls

Control Objective 3: Controls provide reasonable assurance that application and system processing relevant to user entities’ internal controls over financial reporting are executed in a complete, accurate and timely manner, and deviations, problems, and errors are identified, tracked, recorded and resolved.




Computer operations personnel monitor daily and automated operations to verify completion of scheduled processing and document verification on processing checklists.

Inspected processing checklists for a sample of days to determine whether operations personnel monitored processing and documented verification on the checklists.


Processing checklists are reviewed for completeness and signed off on daily by senior computer operations personnel.

Inspected processing checklists for a sample of days to determine whether processing checklists were reviewed by senior computer operations personnel for completeness.


Operations personnel document, track and resolve production systems' schedule deviations in Siebel ISR tickets.

Inspected Siebel ISR tickets for a sample of system and processing deviations to determine whether system deviations were documented, tracked and resolved.


The system automatically records processing activities on the systems console log that is displayed on the system console.

Observed the systems console to determine whether status messages were displayed as production processing occurred.



Page 53

Control Objective 4: Controls provide reasonable assurance that production data files and system software relevant to user entities’ internal controls over financial reporting are backed up regularly and are available for restoration in the event of processing errors or unexpected processing interruptions.




Production environment files are backed up regularly per backup procedures and the execution of backup jobs is captured in daily processing logs.

Inspected backup procedures to determine whether backup procedures were documented.


Inspected ZEKE and NetBatch daily reports for a sample of days to determine whether backups were completed on a daily basis.


Inspected the system report parameters utilized to generate the ZEKE and NetBatch reports to determine whether the appropriate parameters were utilized and no inappropriate data was excluded.


SHAZAM maintains a production location and a backup location to which data is systematically configured to be replicated as updates occur.

Inspected configurations of the EMC data domain backup software to determine whether software was configured to replicate data between the production and backup locations.


Computer operations personnel monitor automated backup jobs daily and complete processing checklists to track job completion and the resolution of processing errors.

Inspected processing checklists for a sample of days to determine whether they were completed to track the status of backup job processing and the resolution of processing errors.



Page 54

Control Objective 5: Controls provide reasonable assurance that system and network performance relevant to user entities’ internal controls over financial reporting are measured and monitored, and that deviations are identified and reviewed for resolution.




Hardware, software and communications problems are documented and communicated on turnover logs by network services personnel to management daily.

Inspected turnover logs for a sample of days to determine whether hardware, software and communications problems were documented and communicated to management daily by network services personnel.


Network services personnel document, track and resolve system and network performance issues within Siebel tickets.

Inspected Siebel tickets for a sample of system and network performance issues to determine whether network services personnel documented, tracked and resolved performance issues.


SolarWinds is used by the NOC for monitoring circuits. SHAZAM is able to view intermittent outages, hard outages and network issues using these tools, and the tools are configured to alert NOC staff when issues occur.

Inspected the SolarWinds dashboard to determine whether it was configured to monitor circuits and hardware for intermittent and hard outages.


Inspected the SolarWinds dashboard to determine whether it was configured to send alerts to NOC staff when issues occur.



Page 55

Physical Access Controls

Control Objective 6: Controls provide reasonable assurance that physical access to computer and other resources relevant to user entities’ internal controls over financial reporting is restricted to authorized personnel.




Physical access to the Des Moines and Johnston facilities, including the on-site data centers, is reviewed and authorized by a GRC analyst annually.

Inspected the annual review of facility and data center access to determine whether an annual facility and data center access review was performed.


Inspected the report query parameters utilized to generate the Master Doors Report used during the annual physical access review to determine whether the appropriate parameters were used and no relevant data was excluded.


SHAZAM has installed security cameras both inside and outside the buildings to detect suspicious activity. Video monitoring and recording of areas within the SHAZAM facilities occurs through video screens monitored by computer operations personnel.

Observed the presence of security cameras and recording equipment to determine whether the Johnston and Des Moines facilities, including the data centers and entrances, were monitored by operations personnel.


Visitors to the facility are required to enter their names into the reception area’s visitor logging software and wear a visitor badge while at the facility. Visitors to the computer rooms are required to sign a computer room visitor log.

Observed the reception area’s visitor logging software to determine whether visitors were entered into the software upon arrival.


Observed visitors entering the facility to determine whether visitors were assigned a visitor badge.


Inspected a computer room log to determine whether visitors to the computer rooms were required to sign a visitor log.


Access cards for new users are requested and approved by the employees’ departmental managers prior to access being provided.

Inspected access request forms for a sample of new users to determine whether access cards were requested and approved by the employees’ departmental managers prior to access being provided.


Human resources notifies SHAZAM security to remove or disable terminated employees’ physical access.

Inspected emails for a sample of terminated employees to determine whether human resources notified SHAZAM security to remove physical access for terminated employees.


Inspected the Master Doors Report for a sample of terminated employees to determine whether physical access was removed or disabled.


Inspected the report query parameters utilized to generate the Master Doors Report used during the annual physical access review to determine whether the appropriate parameters were used and no relevant data was excluded.



Page 56

Control Objective 6: Controls provide reasonable assurance that physical access to computer and other resources relevant to user entities’ internal controls over financial reporting is restricted to authorized personnel.




Cryptographic keys are stored in a separate environment from data-encrypting keys.

Observed the storage of cryptographic keys to determine whether encrypted and key-encrypting keys were stored under dual control.

No exceptions noted


Page 57

Logical Access Controls

Control Objective 7: Controls provide reasonable assurance that logical access to programs, data and computer resources relevant to user entities’ internal controls over financial reporting is restricted to authorized users.




Policies and operational procedures have been defined for security administration and end user responsibilities.

Inspected the Corporate Security Policy to determine whether it defined end user logical access responsibilities.


Logical access to Windows Active Directory is controlled through an authentication mechanism and includes the following system parameters:

Password length = 12 characters

Password expiration = 90 days

Password history = eight passwords remembered

Account lockout = five invalid attempts

Password complexity = alphanumeric and special characters

Inspected Windows Active Directory password settings to determine whether the following configuration settings were in place.



Password history = eight passwords remembered




Logical access to the IBM system requires users to authenticate using at least the following password parameters:

Password length = eight characters


Password history = eight iterations

Account lockout = four invalid attempts


Inspected RACF password settings for the IBM mainframe to determine whether the following configuration settings were in place:








Page 58





7.4 Logical access to the HP systems require users to authenticate using at least the following password parameters:






Inspected SafeGuard and NetPass password settings for the HP systems to determine whether at least the following configuration settings were in place:







7.5 The CA RiskMinder™ client enforces user account and password parameters for access to the SHAZAM Access web portal including the following parameters:





Inspected CA RiskMinder™ password parameters to determine whether the following parameters were enforced:






7.6 Logical access to SHAZAM ACH requires users to authenticate using at least the following password parameters:



Password history = six iterations


Inspected ISAM password settings in place for SHAZAM ACH to determine whether at least the following configuration settings were in place:



Password history = six iterations




Page 59





7.7 Human resources personnel send a termination checklist to the security group to remove or disable a terminated employee’s logical access when an employee is terminated.

Inspected system access listings within the IBM, LAN and HP systems for a sample of terminated employees to determine whether access rights were removed or disabled.


Inspected the termination checklist for a sample of terminated employees to determine whether the security team completed a termination checklist to document the removal of an employee’s access to systems.


7.8 The SHAZAM Access web portal uses TLS encryption on the front-end that protects data transmitted over the internet from unauthorized access.

Inspected the certificate used on the SHAZAM Access web portal to determine whether TLS encryption was enabled.


7.9 An online system access form (SAF) is required to be completed by department supervisors as authorization for granting access to systems and applications.

Inspected SAFs for a sample of new users to determine whether access rights to systems and applications were approved by the department supervisor.


7.10 The eTrust application and UNIX security configurations are used to restrict file permissions to the UNIX systems (RedHat and AIX).

Attempted to access UNIX files where permissions were granted in eTrust but not in UNIX to determine whether access was denied.


Attempted to access UNIX files where permissions were granted in UNIX but not in eTrust to determine whether access was denied.


7.11 eTrust automatically sends email notifications to the UNIX technology group for review of failed access attempts.

Inspected the eTrust alert script and automated email alert to determine whether automated failed access attempt alerts are sent to the UNIX technology group for review.


7.12 Intrusion prevention and detection systems have been implemented to alert SHAZAM personnel regarding potentially unauthorized access attempts within the production HP and IBM environments.

Inspected the configuration of the TippingPoint intrusion prevention and detection system to determine whether it was configured to alert SHAZAM personnel regarding potentially unauthorized access attempts.


7.13 PINs are encrypted during transmission to and from SHAZAM.

Inspected the system configuration to determine whether PIN encryption was enabled.


7.14 SHAZAM establishes financial institution security administrators who are responsible for safeguarding the use of SHAZAM Access for report and data transmissions after completion of an authorization form from the requesting client.

Inspected SHAZAM Access Administrator Account Request Forms for a sample of administrator requests to determine whether financial institution management authorized the request prior to SHAZAM establishing the administrator account.



Page 60





7.15 Access reviews performed on SHAZAM systems, including access to the IBM and HP production environment, databases, IBM and HP source code and the SHAZAM network are reviewed by SHAZAM security operations on a semiannual basis. Changes and modifications identified during the review are addressed as needed.

Inspected a sample of semiannual access review reports to determine whether access reviews for the following systems were reviewed and monitored by information security on a semiannual basis and changes identified during the review were addressed as needed:

HP production

HP source code

IBM production

IBM source code

Active Directory

SHAZAM Access

SHAZAM ACH


Inspected the report query parameters utilized to generate the access listing used during the semiannual review of access to SHAZAM EFT systems to determine whether the appropriate parameters were used and no relevant data was excluded.



Page 61

System Development and Maintenance Controls

Control Objective 8: Controls provide reasonable assurance that changes to application programs and related data management systems relevant to user entities’ internal controls over financial reporting are authorized, tested, documented, approved and implemented to result in the complete and accurate processing and reporting of transactions and balances.




The SHAZAM Enterprise Management Team, made up of senior vice presidents, meets weekly to provide oversight and prioritization to authorize the start of enterprise projects resulting in changes to production.

Inspected the Enterprise Management Team meeting minutes for a sample of weeks to determine whether the Management Team met to discuss projects resulting in changes to production.


SHAZAM uses a systems development methodology for development/maintenance projects to guide programming personnel in the design, testing authorization and implementation of system modifications.

Inspected system development methodology process flows to determine whether they addressed the design, testing, authorization and implementation of system modifications.


A request to change an existing program is submitted in writing on a standard request form and is approved by management prior to implementation.

Inspected change request forms for a sample of individual program changes to determine whether the changes were documented and approved by management prior to implementation.


Functional specifications for new product development projects are developed and documented in a Technical Response document or IT Impact Analysis.

Inspected technical response documentation for a sample of new product development projects to determine whether functional specifications were documented.


Programs to be implemented are tested; a record of testing is maintained in IT Change Request Forms. For project level changes, testing documentation is retained in the online project documentation repository.

Inspected change request forms for a sample of individual program changes to determine whether testing was completed.


Inspected the change request form for a sample of projects to determine whether testing of the associated application changes was completed prior to implementation.


At the completion of projects, the project requester, project requester’s manager and an application development manager are required to approve the individual program change for release to production.

Inspected change request forms for a sample of new product development projects to determine whether the changes were approved prior to release into production.


A library management tool is used for the legacy IBM platform that restricts programmers from checking in and approving their own programs.

Observed the IDS library management tool used to control access to legacy source code to determine whether the system required a second-level approval by another programmer and restricted programmers from approving their own programs.



Page 62

Control Objective 8: Controls provide reasonable assurance that changes to application programs and related data management systems relevant to user entities’ internal controls over financial reporting are authorized, tested, documented, approved and implemented to result in the complete and accurate processing and reporting of transactions and balances.




Access reviews performed on SHAZAM systems, including access to the IBM and HP production environment, IBM and HP source code the SHAZAM network, SHAZAM ACH, and SHAZAM Access are reviewed by SHAZAM security operations on a semiannual basis. Changes and modifications identified during the review are addressed as needed.

Inspected a sample of semiannual access review reports to determine whether access reviews for the following systems were reviewed and monitored by information security on a semiannual basis and changes identified during the review were addressed as needed:

HP production

HP source code

IBM production

IBM source code




Reperformed management’s review of access permissions for the IDS software control tool to determine whether the ability to update the IBM mainframe production environment was restricted to personnel based on job responsibility and those individuals did not have access to make changes to source code.


Reperformed management’s review of access rights to the production environment where web application code was stored to determine whether access to the production code was restricted to production support personnel who did not have access to source code.


Reperformed management’s review of active account permissions to the HP mainframe (via the production pathway) to determine whether the ability to update the production environment was restricted to individuals who did not have access to make changes to source code.



Page 63

Control Objective 9: Controls provide reasonable assurance that the system infrastructure is configured as authorized to support the effective functioning of application controls to result in valid, complete and accurate processing and reporting of transactions and balances and protect data from unauthorized changes.




SHAZAM has a change management policy that establishes the process for authorization and implementation of modifications to hardware, software and data that are undertaken by the IT departments.

Inspected the Information Technology Change Control Policy to determine whether a policy was documented and defined the process for authorization and implementation of hardware, software and data changes.


System build specifications and standards are documented.

Inspected build standards used for configuring new Windows and UNIX systems to determine whether standards and specifications were documented.


Changes to system hardware are initiated and documented within IT change request forms and are approved for use prior to implementation by designated IT managers.

Inspected IT change request forms for a sample of changes made to system hardware to determine whether system changes were documented within IT change request forms and approved for use by designated management prior to implementation.


Access reviews performed on SHAZAM systems, including access permissions to make system hardware changes are reviewed by SHAZAM security operations on a semiannual basis. Changes and modifications identified during the review are addressed as needed.

Inspected a sample of semiannual access review reports to determine whether access reviews to SHAZAM systems, including permissions to make system hardware changes were reviewed and monitored by information security on a semiannual basis and changes identified during the review were addressed as needed.





Page 64

Application and Business Process Controls

Control Objective 10: Controls provide reasonable assurance that transactions are routed correctly and are processed accurately.




Transaction routing is performed based on a segment of the personal account number (PAN) stored in the terminal control file and bank control file.

Inspected the settlement report for test transactions to determine whether the transactions were automatically routed to the correct institution and identified correctly on the settlement report.


Reperformed test transactions to determine whether transactions were routed to the correct institution completely and accurately.


Transactions are automatically balanced and provided to financial institutions within settlement reports.

Observed a test withdrawal and deposit transaction to determine whether transactions were automatically balanced.


Inspected the settlement report for a test withdrawal transaction to determine whether it was presented accurately and completely on the settlement report.


Reperformed test transactions to determine whether the settlement report was automatically balanced and calculations were complete and accurate.


The sums of debits, credits and number of items transmitted are automatically reconciled to a trailer record included in the bulk data transmission from the Federal Reserve Bank (FRB) to validate its content is complete. Computer operations personnel monitor the reconciliation process for errors on a daily basis as part of the processing checklist.

Inspected the Origination Load and ACH Origination File Reports from the file transmission and the FRB validation response to determine whether the sums of debits, credits and number of items transmitted reconciled to the trailer record received from the FRB.


Inspected processing checklists for a sample of days to determine whether operations personnel monitored the reconciliation process for errors and documented the verification on the checklist.


Observed the routine used for sorting records and ABA sequence to determine whether it automatically reconciled the debits, credits and number of items completely and accurately to the FRB.


ACH receipt records for distribution to clients are automatically sorted by ABA number and separate files are created for the financial institutions. ABA numbers are stored in the bank control file.

Observed the routine used for sorting records and inspected the sorting in ABA sequence to determine whether it was automatically performed.



Page 65

Control Objective 10: Controls provide reasonable assurance that transactions are routed correctly and are processed accurately.




Modifications to the bank control file are documented and assigned to the client implementation services group responsible for bank control file changes. Changes are approved by a manager prior to implementation.

Inspected Siebel tickets for a sample of bank control file modifications to determine whether the modifications were assigned to the group responsible for bank control file changes and approved by a manager prior to implementation.



Page 66

Control Objective 11: Controls provide reasonable assurance that modifications to the online PAN databases are authorized, secure, and assigned to a designated SHAZAM support group.




Modifications to the PAN and bank control file online databases are authenticated through a secured file transfer system.

Inspected a client institution connection to SHAZAM Access to determine whether TLS encryption for data transfers was utilized.


Modifications that are needed or requested to the financial institutions’ online databases are documented and assigned to the SHAZAM production support group for implementation. Changes are approved by management.

Inspected Siebel tickets for a sample of PAN database change requests to determine whether they were assigned to the responsible SHAZAM support group and approved by management.



Page 67





Transactions are received in a predefined format that contains cardholder identifiers and required information, such as a PIN, to complete the transaction. The transactions are authenticated using these cardholder identifiers. Invalid transactions are denied.

Inspected the receipts of test transactions for a balance inquiry, deposit and withdrawal transaction with valid cardholder and PIN combinations to determine whether authorization for transaction processing was accepted.


Inspected the receipts of test transactions for authorization attempts with an invalid cardholder and PIN combination to determine whether the transactions were denied.


Transactions are automatically evaluated for authorizations based on parameters specified in the bank control file database and cardholder data documented in the card database.

Inspected card parameters within SHAZAM Access and corresponding transaction receipts for test transactions to determine whether test transactions were processed or denied based on the parameters specified in the database.


Requests for modifications to the card database are submitted online through a secured Internet connection.

Inspected a client institution connection to SHAZAM Access to determine whether TLS encryption for data transfers was enabled.


Inspected Siebel tickets for a sample of bank control file modifications to determine whether the modifications were assigned to the group responsible for bank control file changes and approved by a manager prior to implementation.


Transactions are automatically logged and balanced in settlement reports that are provided to the cardholder financial institution. Authorized and unauthorized transactions are reported on the cardholder institution settlement report.

Inspected settlement reports for a test balance inquiry, withdrawal transaction, authorized, and unauthorized transactions to determine whether they were presented completely and accurately on settlement reports.


Observed settlement reports for financial institutions on the SHAZAM Access repository to determine whether settlement reports were provided to financial institutions daily.




Transactions are rejected if the card is listed on the negative file as documented in the PAN database.

Inspected the receipts of test transactions using a “warm” (i.e., lost) card to determine whether the transaction was denied.


Inspected receipts of test transactions using a “hot” (i.e., stolen) card to determine whether the transaction was denied.



Page 68





12.6 Authorization responses are automatically matched and recorded to the initial authorization request message. Response codes indicating success or failure are reported on the resulting settlement report.

Inspected receipts and a settlement report for a test authorization transaction with a valid card and PIN to determine whether the corresponding settlement report matched the action code that was printed on the receipt.


Inspected the receipts and settlement report for a test authorization test transaction with an invalid PIN to determine whether the corresponding settlement report matched the resulting transaction action code that was printed on the receipt.



Page 69

Control Objective 13: Controls provide reasonable assurance that transmissions to and from the clearinghouse are secure and processed completely.




Transmissions to and from the FRB are encrypted and occur over a dedicated leased line using software required by the FRB.

Observed the leased line within the data center to determine whether a dedicated leased line was used to communicate with the FRB.


Inspected the output log to determine whether operations personnel utilized the FRB-required software, Connect:Direct.


Inspected the security settings for the Connect:Direct Secure+ data transmission software to determine whether encryption was enabled.


Information received from the FRB, which includes pending transmissions to financial institutions, and information received from financial institutions, which includes pending transmissions to the FRB, are written to secure staging files.

Inspected Goldleaf storage configurations to determine whether information pending transmission to financial institutions or the FRB are written to secure staging files.


The sums of debits, credits and number of items transmitted are automatically reconciled to a trailer record included in the bulk data transmission from the FRB to validate its content is complete. Computer operations personnel monitor the reconciliation process for errors on a daily basis as part of the processing checklist.

Inspected the output from the file transmission and the FRB validation response to determine whether the sums of debits, credits and number of items transmitted reconciled to the trailer record received from the FRB.


Inspected processing checklists for a sample of days to determine whether operations personnel monitored the reconciliation process for errors and documented the verification on the checklist.


Observed the routine used for sorting records and ABA sequence to determine whether it automatically reconciled the debits, credits and number of items completely and accurately to the FRB.


Transmissions from the financial institutions occur using password-protected transmission software.

Observed a user log into the ACH transmission software to determine whether passwords were required.



Page 70

Control Objective 14: Controls provide reasonable assurance that the system is in balance prior to settlement and net settlement amounts are computed completely and accurately.




Finance is automatically notified of potential out-of-balance settlement conditions. Notifications are researched and resolved by finance and documented within Siebel tickets.

Inspected system configurations to determine whether finance was automatically notified of out-of-balance settlement conditions.


Inspected Siebel tickets for a sample of out-of-balance settlement conditions to determine whether the conditions were researched and resolved by finance.

No tests of operating effectiveness occurred as the circumstances that warrant the operation of the control did not occur during the report period; there were no out-of-balance notifications

The finance department reconciles settlement accounts on a daily basis to ensure net settlement amounts are computed completely and accurately by balancing the sum of the internal and external detail to SHAZAM’s bank account within a settlement spreadsheet. Issues identified during the reconciliation are resolved by finance prior to settlement.

Inspected settlement spreadsheets for a sample of days to determine whether finance reconciled settlement accounts to bank account activity on a daily basis and addressed any issues identified prior to settlement, if needed.


Inspected a sample of line items from the reconciliation and traced to source documentation to determine whether the data represented within the debt settlement report was represented completely and accurately.


Financial institutions are provided settlement information reports daily, which are automatically posted to the SHAZAM Access repository.

Inspected the report query parameters utilized to generate the debt settlement report and bank account activity reports used by finance to perform the reconciliation to determine whether the appropriate parameters were used and no relevant data was excluded.







Page 71

Control Objective 15: Controls provide reasonable assurance that customer switch billings are authorized and processed in a complete and accurate manner.




Standard billing for requested services is setup by the implementation team based on a set fee schedule to ensure complete and accurate billing.

Inspected service agreement terms and fee schedules for a sample of new financial institutions to determine whether standard billing rates were accurately set up in the system.


Standard billing invoices are automatically generated based on activity from the past month using a standard fee schedule.

Reperformed billing calculations for a standard billing invoice to determine whether the invoice was automatically calculated using a standard fee schedule and the calculations were complete and accurate.


Clients that request unique billing terms must have the terms reviewed and approved by managing director of sales prior to being implemented.

Inspected pricing approval forms a sample of unique billings to determine whether they were reviewed and approved by SHAZAM’s senior management prior to being implemented.


Invoices with miscellaneous charges included are reviewed by the finance department monthly and a documented checklist is completed by finance personnel and retained.

Inspected miscellaneous billing checklists for a sample of months to determine whether a monthly review of invoices with miscellaneous charges was performed by the finance department.


Billing adjustments and disputes are reviewed and approved by finance department management.

Inspected adjustment and dispute forms for a sample of adjustments and disputes to determine whether they were approved by management.



Page 72

Control Objective 16: Controls provide reasonable assurance that debit chargebacks or unsatisfactory settlements are monitored for timely resolution, and are based on written procedures that coincide with applicable network rules.




SHAZAM chargeback specialists are provided applicable Visa and Mastercard documentation as reference in order to comply with chargeback and representment requirements.

Inspected documents provided by Visa and Mastercard to determine whether reference chargeback and representment requirements were documented.


Incoming exception item information from Mastercard and Visa signature-based issuers is automatically entered into a tracking system in order to monitor the progress of exceptions toward resolution.

Inspected filebound files for a sample of items from Mastercard and Visa exception and representment reports to determine whether they were entered into the tracking system for monitoring.


The manager of chargebacks is notified automatically via a Siebel ISR email when a Visa representment is entering the 35-day age range.

Inspected filebound files for a sample of items from Mastercard and Visa exception and representment reports to determine whether they were entered into the tracking system for monitoring.


Finance reviews debit transaction chargebacks and unsatisfactory settlement exception items on a daily basis.

Inspected transaction summarizations for a sample of days to determine whether exception items were reviewed by finance.


Inspected the ISR Alerting configuration to determine whether it was configured to automatically send an alert to the chargeback manager when a Visa representment was entering the 35-day age range.


Inspected a sample of line items from the reconciliation and traced to source documentation to determine whether the data represented within the debt settlement report was represented completely and accurately.


The finance department reconciles FDR exception items monthly between the FDR system and the offline SHAZAM system. Identified discrepancies are researched and resolved prior to completing the reconciliation.

Inspected Chargeback Suspense Reconciliation summarizations for a sample of days to determine whether the reconciliation was performed by the finance department and any exception items were reviewed by finance.



Page 73

Control Objective 17: Controls provide reasonable assurance that periodic credit reviews and fraud investigations are performed, monitored and reported for follow-up.




SHAZAM has a designated fraud department staffed with associates with defined position descriptions.

Inspected job descriptions for a sample of fraud department job titles to determine whether associate responsibilities and skills were defined.


SHAZAM has documented procedures to assist fraud operations staff in the performance of their duties.

Inspected fraud operations procedures to determine whether monitoring tasks and actions were defined to assist fraud operations staff in the performance of their duties.


Debit card transactions flow through Falcon and are automatically assigned a score based on the level of risk associated with the transactions on the account. If the transaction(s) are assigned a risk score over a predetermined threshold, the system automatically creates a “case” to be reviewed by SHAZAM fraud operations specialists.

Observed the use of the Falcon software to determine whether possible fraudulent activity was automatically assigned to a “case” with an assigned priority based on the calculated level of risk.


Cases created are assigned to queues that are prioritized based on the level of risk associated with transactions on the accounts. SHAZAM fraud operations specialists work through the cases in the priority order that is populated by Falcon.

Observed work queues within Falcon to determine whether fraud operations specialists worked through the cases based on the queues populated by Falcon.


Financial institutions are provided FD150R reports summarizing work performed by fraud operations if transactions were identified in Falcon for their institution.

Observed system configurations to determine whether financial institutions were provided FD150R reports if transactions were identified in Falcon for their institution.


Observed a live transaction input into the system and traced that transaction to the FD150R report that is automatically created the next day.


SHAZAM’s rules analyst (RS) will write, test and implement rules aimed at detecting high-risk and fraudulent activity.

Inspected change documentation for a sample of applied rules to determine whether they were developed, tested and implemented by a SHAZAM risk analyst.


Prospective national bankcard participants are evaluated for financial soundness. This evaluation is presented during monthly communications to a committee of the board of directors for approval of participation.

Inspected Safety and Soundness Committee documents for a sample of months to determine whether prospective bankcard participants were evaluated.



Page 74

Control Objective 17: Controls provide reasonable assurance that periodic credit reviews and fraud investigations are performed, monitored and reported for follow-up.




Active national bankcard participants are evaluated for financial soundness. This evaluation is presented during monthly meetings to a committee of the board of directors for approval of participation.

Inspected Safety and Soundness Committee documents for a sample of months to determine whether active bankcard participants were evaluated.



Page 75

Control Objective 18: Controls provide reasonable assurance that client reports are generated and distributed in a secure manner.




Financial institutions have individual areas on the SHAZAM Access web portal to view and retrieve reports.

Inspected SHAZAM Access report repositories for a sample of financial institutions to determine whether financial institutions had individual areas on the SHAZAM Access web portal to view and retrieve reports.


Client reports are automatically generated on a daily basis and made available to customers on the SHAZAM Access web portal.





SHAZAM Access requires users to be authenticated users in order to access their institution’s report repository.

Observed an access attempt within the SHAZAM Access web portal to determine whether users were required to authenticate in order to access their institution's report repository.


The CA RiskMinder™ client enforces user account and password parameters for access to the SHAZAM Access web portal, including the following parameters:





Inspected CA RiskMinder™ password parameters to determine whether the following parameters were enforced:






Defined user roles control access permissions within the SHAZAM Access web portal.

Inspected the listing of SHAZAM Access roles to determine whether they were defined to control user access.


The SHAZAM Access web portal uses TLS encryption on the front-end that protects data transmitted over the Internet from unauthorized access.

Inspected the certificate used on the SHAZAM Access web portal to determine whether TLS encryption was enabled.



Page 76

Control Objective 19: Controls provide reasonable assurance that new clients are authorized and set up in accordance with client instructions and guidelines in a complete and accurate manner.




SHAZAM has documented policies and procedures for implementation personnel to assist in the setup of new clients in the system.

Inspected the implementation policies and procedures to determine whether procedures were documented to assist implementation personnel in the setup of new clients in the system.


Client contracts and agreements are completed and maintained for new clients to document client setup and to authorize the implementation of new clients.

Inspected client contracts and agreements for a sample of new clients to determine whether the agreements were completed and they authorized the implementation of the client into the system.


SHAZAM implementation staff complete a project checklist to document the client setup in accordance with client instruction.

Inspected the implementation project checklist for a sample of new clients to determine whether the client was provisioned by SHAZAM implementation staff in accordance with the client instructions.


Project managers complete a post-implementation verification checklist to verify that new client setup was completed in a complete and accurate manner.

Inspected the post-implementation verification checklist for a sample of new clients to determine whether project managers verified that the client was provisioned in accordance with the client instructions.


Standard billing for requested services is set up by the implementation team based on a set fee schedule to ensure complete and accurate billing.

Inspected service agreement terms and fee schedules for a sample of new financial institutions to determine whether standard billing rates were accurately set up in the system.


SHAZAM, INC. OTHER INFORMATION PROVIDED BY SHAZAM, INC.

Page 77

V. Other Information Provided by SHAZAM, Inc.

This section from SHAZAM provides additional information to user organizations and is not a part of SHAZAM’s description of controls placed in operation. The information in this section has not been subjected to the procedures applied in the examination of the EFT systems description for processing transactions and, accordingly, RSM US LLP expresses no opinion on it.

Due Diligence Information

The SHAZAM Access web portal contains comprehensive due diligence information for SHAZAM participants. This information is accessible through the Audit and Compliance tab on the SHAZAM Access home page. Information is available on the following topics:

Statement on Standards for Attestation Engagements No. 18 (SSAE 18) Service Organization Control (SOC) 1 reports

Regulation E—Overdraft Rules

Information security

- Summary of Information Security Program

- Multifactor authentication information

- Web portal security controls

- Security Assessment Program

- Payment Card Industry (PCI) compliance information and letter

- Employee background screening practices

- Data Breach Investigations Report

Privacy and identity theft information

- Gramm-Leach-Bliley Act (GLBA) processing agreement contract addendum

Business Continuity Program

Financial information

Insurance information

Miscellaneous information

- NACHA self-audit

- SHAZAM annual reports

- Information on how to obtain an FFIEC IT examination report

- Letter of assurance to the Iowa Division of Banking

- SHAZAM Secure® service information


Page 78

SHAZAM Insight

SHAZAM Insight is a reporting tool built into the SHAZAM Access web portal that allows SHAZAM clients to generate executive-level reports on demand. The reports contain both terminal- and transaction-level information that is used to plan terminal locations and merchant partnerships or determine which cardholders are experiencing denied transactions.

Information Security and Privacy

The Gramm-Leach-Bliley Act (GLBA) has increased the importance of physical and logical security over information systems and client data. SHAZAM plays an important role in providing information services to financial institutions and merchants. These clients rely on a sound internal control environment at SHAZAM to help them comply with the GLBA.

While SHAZAM cannot verify its clients will fully comply with the GLBA, SHAZAM has designed its controls to assist user organizations in complying with the legislation and regulations. The following table lists the specific GLBA requirements and the associated control objectives of this report that describe the company’s adherence to the requirements.

GLBA Requirement (1) SHAZAM Report Reference

C.1.a Access controls over customer information systems

Logical Access Controls: Control Objective 7

C.1.b Access restrictions at physical locations Physical Access Control: Control Objective 6

C.1.c Encryption of electronic customer information PIN Processing: Control Objective 12

C.1.d Controls over system modifications System Development Methodology: Control Objective 8 and 9 Logical Access Controls: Control Objective 7 Computer Operations: Control Objective 3 and 5

C.1.e Dual control procedures, segregation of duties and background checks for employees

Organization and Administration: Control Objective 1 and 2

C.1.f Monitoring systems and procedures to detect actual and attempted attacks on or intrusions into customer information systems


C.1.g Response programs when an institution suspects or detects unauthorized access


C.1.h Measures to protect against destruction, loss or damage of customer information due to environmental hazards

Section V

C.2 Staff training on the Information Security Program Organization and Administration: Control Objective 1 Logical Access Controls: Control Objective 7

C.3 Regular testing of key controls, systems and procedures of the information security program


D. Oversight of service provider arrangements SHAZAM has a formal oversight program in place for service providers and vendors.

(1) The information provided in the above table is based on the information provided at the source cited. The GLBA regulation applications may vary based on the federal oversight agency responsible for the regulations. The GLBA information was extracted from the final rule published by the Office of the Comptroller of the Currency. Implemented and proposed regulations are subject to change.


Page 79

SHAZAM has implemented a privacy policy that prohibits the sale or distribution of client data. Data may only be shared with business partners as necessary in normal transaction processing. Additionally, SHAZAM’s enterprise risk and security department performs proactive procedures to verify adherence to the policy. For more information on SHAZAM’s privacy program, please contact SHAZAM’s legal counsel.

SHAZAM Initiatives and Product Changes

Throughout the year, SHAZAM staff members in every department and at every corporate level work to improve internal and external business processes and develop innovative ways to “work smarter.” These efficiencies and innovations have resulted in improvements to our service to you.

Significant investments in our network infrastructure, including a firewall and intrusion prevention system upgrade and numerous other system enhancements, support increasing transaction volumes and position us for future growth. We have added new products and services, upgraded hardware and software, increased internal efficiencies and created materials to help your financial institution grow in this competitive market.

Your feedback has initiated several improvements to existing SHAZAM products and services. When you communicate your business needs to SHAZAM, we research and identify product improvements that bring you the most value.

Updated SHAZAM Technology, Products and Services

The following describes how SHAZAM gives your financial institution a competitive edge in the marketplace through innovative technology upgrades, the introduction of new products and services, and enhancements to our existing products and services.

Mobile services

SHAZAM expanded its mobile wallet support (from ApplePay alone) to include AndriodPay, SamsungPay, Microsoft Wallet and “card on file.” Improvements were also made to secure, self-service provisioning of tokens into the wallets.

SHAZAM® BOLT$™ allows cardholders to set email alert preferences for their SHAZAM cards and retrieve real-time card balances through an iOS or Android™ device. The service offers alerts triggered by FICO® Falcon® fraud cases, internet merchant, international merchant and threshold dollar amount exceeded. SHAZAM® BOLT$™ allows for issuer-specific branding and terms and conditions. During this year, we improved the notification service by adding SMS text messaging. We added the ability for cardholders to use the alerting criteria to optionally decline transactions. We expanded our reach, by allowing financial institutions to put BOLT$ functionality in their own existing internet and mobile banking applications through a suite of web service APIs.

SHAZAM-brand enhancements

The network made changes to brand rules and processing to accommodate the use of the SHAZAM brand for eCommerce. The changes allow eCommerce merchants to send pinless debit, single message POS transactions through SHAZAM. The network also made significant progress in its work to enable dual message “signature debit.” These changes allow use of the brand in places like travel and entertainment and eCommerce where previously perhaps only competing signature debit brands could be used. Acquirers and issuers will both benefit financially, because SHAZAM is more efficient, affording a lower cost for the merchant and higher net interchange income for the issuer.


Page 80

Payment Card Industry Data Security Standard

Annual Assessment

SHAZAM annually contracts with a PCI Security Standards Council LLC (PCI SSC) approved Qualified Security Assessor (QSA) to perform a PCI assessment to validate the compliance of SHAZAM’s facilities with published PCI security guidelines and requirements.

The PCI Data Security Standard (DSS) assessment process focuses on the security of cardholder data, whether SHAZAM has effectively implemented information security policies and processes and if there are adequate security measures to comply with the requirements to protect cardholder data. Additionally, the assessment reviews whether SHAZAM is employing industry best practices and provides recommendations for remediation of noncompliant policies, processes, procedures, system configurations or vulnerabilities.

According to the most recent annual assessment, SHAZAM is compliant with PCI DSS requirements.

Quarterly Scan Results

As part of the PCI DSS requirements, SHAZAM’s internet portal is scanned quarterly for vulnerabilities. The remote vulnerability assessment of SHAZAM’s internet-accessible systems is conducted by a PCI SSC-approved scanning vendor using a PCI vulnerability scanning engine. The scan covers identified systems and IP addresses of SHAZAM’s external internet presence. According to the most recent scan, SHAZAM is compliant with the PCI DSS quarterly scanning requirement.

Business Continuity

SHAZAM’s goal is to provide dependable, quality service to participants. To uphold this goal, SHAZAM understands the need to have a prepared response to possible service interruptions. SHAZAM realizes significant or prolonged downtime of services could directly and adversely affect its many financial institution clients. Therefore, SHAZAM maintains a comprehensive and updated Business Continuity Plan (BCP) to verify a quick and fundamentally seamless transition to alternative operations in a disaster situation. These alternatives are tested at least annually.

SHAZAM has developed disaster recovery information that outlines the recovery strategies to follow in the event of a localized disaster, including 1) a business recovery plan that is updated regularly to verify current information for dealing with a recovery event from a business operation perspective, and 2) specific procedures for recovering the EFT systems. To facilitate the recovery effort, SHAZAM has built its own facility to provide backup processing facilities and certain computer operation services.

SHAZAM’s overall BCP contains the following components:

Statement on Standards for Attestation Engagements No. 16 (SSAE 16) reports

Board of directors and senior management oversight

Business impact analysis maintenance

Contingent facilities

Risk assessment

Strategy and documentation

Planning and integration within company processes


Page 81

Testing

Audit and independent review

Regular updates and enhancements

SHAZAM continues to enhance its overall BCP in several respects, and the company believes it is well-positioned to implement its disaster recovery processes with effective results. SHAZAM is confident that in the unlikely event of a disaster that incapacitates facilities, downtime of critical services would not be prolonged. SHAZAM’s current BCP strategy supports a transparent recovery for participants and their cardholders.

Participating financial institutions are responsible for developing their own contingency plans to complement the SHAZAM effort and to comply with the Federal Financial Institutions Examination Council (FFIEC) interagency statement on corporate business resumption and contingency planning description policy statement.

Operating Environment Resiliency

SHAZAM’s production data center is housed in a facility in Johnston, Iowa, specially constructed for SHAZAM. The secondary data center was constructed to mirror the primary site. SHAZAM implemented measures to protect the data center and communication facilities and to provide backup hardware and redundant telecommunications capabilities.

These measures are briefly described below:

The production data center is staffed 24/7.

Video monitoring and recording of the facility occurs through a closed-circuit television (CCTV) system monitored by computer operations personnel.

The Johnston facility has separate buried lines that merge prior to connecting to the transformer from two separate electrical power substations.

Buried fiber optic telecommunication lines provide redundant communication to SHAZAM’s Johnston data center along separate paths from the telephone central office.

SHAZAM has backup/redundant units for key hardware components on the network, including multiple central processing units (CPUs), communications processors, disk drives and tape drives.

Computer Operations Monitoring Initiatives

SolarWinds network monitoring software is used to assist operations staff in quickly detecting and diagnosing network performance issues and outages, as well as other definable monitors and alerts for Windows-related issues.

Other PIN Processing and Key Management Information

PIN Processing

For cardholder data processing centers (DPCs), the exchange key is completed by using two 32- or 48-digit hexadecimal components for 3DES. One component is created by the DPC, and the other is created by SHAZAM. The components are exchanged via non-postal certified delivery services, and the SHAZAM key custodians independently enter the data under dual control. Data is validated against check values for accuracy. For ATM and POS terminals, SHAZAM allocates terminal master key components and sends them to the financial institutions.


Page 82

These components are randomly generated, sealed and assigned to a financial institution by security operations. The FI then needs to activate the Comvelope© in the IVR system with a pre-assigned PIN for the component to become active.

SHAZAM provides member and participant financial institutions with a summary of key management suggested practices when releasing cryptographic key material to these institutions. Included in this summary are web addresses where the institutions can review guidance on key management from the PCI SSC.

Key Management

Storing Clear Text Encryption Key Components

Components are stored in clear text in different media, including paper forms, programmable read-only memory (PROM) and smart cards. SHAZAM stores key components under dual control using secured storage mechanisms. SHAZAM maintains logs noting times when the components are accessed.

Transporting and Distributing Clear-Text Encryption Key Components

To enforce dual control during transit and at the end-user level, SHAZAM sends key components to separate, authorized financial institution key custodians in tamper-evident packaging. The sending custodians record the retrieval, sending or use of the encryption key component in an Encryption Key Log. SHAZAM provides member and participant financial institutions with a summary of key management industry practices when releasing cryptographic key material to these institutions. Included in this summary are web addresses where the institutions can review guidance on key management from the PCI SSC.

Storing and Distributing Inactive Encryption Key Components

Inactive components used for creation of unique initial terminal keys are not managed under enforcement of split knowledge and dual control. These inactive components are randomly generated 32 hexadecimal character numbers, contained in anonymous tamper-evident Comvelopes.

Randomly selected inactive components are combined when entered into an ATM to create a unique key. A control number assigned to the random component is stored at a tamper-resistant security module (TRSM), encrypted under the master file key (MFK) of the TRSM. After combining these components at the ATM, the control numbers are communicated to the TRSM by the financial institution through an interactive voice response (IVR) system. This prompts the TRSM to combine the components into an initial key identical to the key now stored in the ATM. Finally, the TRSM encrypts the new key under a shared key encryption key (KEK) and uses the established host command interface to communicate the new cryptogram to the ATM.

Destroying Encryption Key Components

Key components are destroyed whenever a key is considered compromised or after the key is no longer in use. Destruction methods will vary according to the media on which the component is stored. For paper media, the preferred method is to use a cross-cut shredder. For PROMs and smart cards, SHAZAM follows the directions of the HSM vendor. SHAZAM conducts key destruction under the concept of dual control, in which the two involved custodians log the destruction details within a central log.

Logging and Record-Keeping

SHAZAM records actions related to key components. Key custodians record the name and signature of the custodian, the type of key, the number of the component, the date and time of the action, the serial number of the tamper-evident envelope and the action involved within its key access logs. The log is kept separate from the key material itself.

shazam, inc....shazam, inc.’s controls throughout the period january 1, 2017, to october 31, 2017....

Documents