Oklahoma!Turnpike!Authority! RequestforProposal15:002 ... Licens… · Oklahoma!Turnpike!Authority!–!Request!for!Proposal!! 2015!! 5!! Oklahoma!City,!OK!73107!! PROPOSAL!DUE!DATE:!12:00!p.m.!Central!Daylight!Time,!July!24,2015!

0

Oklahoma Turnpike Authority Request for Proposal 15-‐002

License Plate Tolling

Oklahoma Turnpike Authority – Request for Proposal 2015

1

Table of Contents

1. INTRODUCTION ...................................................................................................................................................... 3

2. BACKGROUND ......................................................................................................................................................... 3

3. SCOPE OF SERVICES TO BE PROVIDED ............................................................................................................ 3

4. CONTRACT TERM ................................................................................................................................................... 4

5. INSTRUCTIONS TO PROPOSERS ........................................................................................................................ 4 5.1 MANDATORY PRE-‐PROPOSAL MEETING ............................................................................................................................ 4 5.2 WRITTEN QUESTIONS .................................................................................................................................................... 4 5.3 ORAL PRESENTATION ..................................................................................................................................................... 4 5.4 BEST AND FINAL OFFER ................................................................................................................................................. 4 5.5 PROPOSAL SUBMITTAL REQUIREMENTS ............................................................................................................................ 4 5.6 MODIFICATION AND WITHDRAWAL OF PROPOSAL .............................................................................................................. 5 5.7 AUTHORITY POLICY ....................................................................................................................................................... 6 5.8 SCHEDULE ................................................................................................................................................................... 6 5.9 KEY DATES ................................................................................................................................................................... 6

6. PROPOSAL FORMAT .............................................................................................................................................. 6 6.1 COVER LETTER .............................................................................................................................................................. 6 6.2 TABLE OF CONTENTS ..................................................................................................................................................... 7 6.3 UNDERSTANDING OF THE PROJECT AND ABILITY TO MEET ALL REQUIREMENTS ........................................................................ 7 6.4 FIRM’S QUALIFICATIONS, EXPERIENCE AND FINANCIAL SUSTAINABILITY .................................................................................. 7 6.5 PROJECT TEAM’S QUALIFICATIONS, RELEVANT EXPERIENCE AND ORGANIZATION ..................................................................... 8 6.6 PROPOSED PROJECT IMPLEMENTATION SCHEDULE .............................................................................................................. 9 6.7 PRICE PROPOSAL .......................................................................................................................................................... 9 6.8 ALTERNATE METHODOLOGY ......................................................................................................................................... 10 6.9 EVIDENCE OF INSURABILITY/INSURANCE/APPLICABLE LICENSE ............................................................................................ 10 6.10 BID BOND ............................................................................................................................................................... 10

7. EVALUATION PROCESS AND SELECTION CRITERIA .................................................................................. 11

8. VALIDITY OF PROPOSAL .................................................................................................................................... 11

9. NOTICE OF AWARD .............................................................................................................................................. 11

10. GENERAL CONDITIONS .................................................................................................................................... 11 10.1 TAXES ..................................................................................................................................................................... 11 10.2 CONFIDENTIALITY AGREEMENT .................................................................................................................................... 12 10.3 INDEPENDENT CONTRACTOR ....................................................................................................................................... 12 10.4 ASSIGNMENT ........................................................................................................................................................... 12 10.5 TERMINATION AT THE AUTHORITY’S OPTION ................................................................................................................. 12


2

10.6 INDEMNITY .............................................................................................................................................................. 12 10.7 PUBLICITY ................................................................................................................................................................ 13 10.8 INSURANCE .............................................................................................................................................................. 13 10.9 BONDS .................................................................................................................................................................... 14 10.10 ESCROW ................................................................................................................................................................ 14 10.1 REVENUE LOSS ......................................................................................................................................................... 15 10.2 PUBLIC AVAILABILITY TO RFP RECORDS ........................................................................................................................ 16 10.3 AUDIT OF RECORDS ................................................................................................................................................... 16 10.4 OTHER TERMS & CONDITIONS .................................................................................................................................... 16


3

1. INTRODUCTION

The Oklahoma Turnpike Authority (Authority) is requesting proposals for a License Plate Tolling back office solution. The purpose of this RFP is to solicit proposals from experienced vendors to operate a back office for processing all video-‐based tolls from a new All Electronic Tolling interchange on the Oklahoma Turnpike.

2. Background

The Oklahoma Turnpike Authority is an instrumentality of the State of Oklahoma. The Authority is authorized to construct, maintain, repair, and operate turnpike projects at locations authorized by the Legislature of the State of Oklahoma and approved by the State Department of Transportation. The Authority receives revenues from turnpike tolls, investments and a percentage of the turnpike concession sales. The Toll revenue for 2014 was $246 million.

Across the state, the Authority operates and maintains ten turnpikes. Turnpike lane configurations consist of electronic toll collection (PIKEPASS), automatic coin machine, manual toll collection and mixed configurations of each. A violation enforcement system is utilized on a number of the PIKEPASS and automatic coin machine lanes.

3. SCOPE OF SERVICES TO BE PROVIDED

The Authority is considering a phased introduction of an All Electronic Tolling (AET) system. As part of its evaluation process, the Authority will convert the Elm/Peoria Interchange on the Creek Turnpike in the city of Jenks to AET. This interchange is being reconstructed as part of a partnership with the city of Jenks in a large economic development effort by the city. The Authority is taking advantage of the reconstruction efforts to test this conversion to AET. Once the Elm/Peroria interchange is converted, customers must pay electronically, either with a valid PIKEPASS transponder, Kansas Turnpike Authority KTA tags, North Texas Tollway Authority (NTTA) Tolltags or through License Plate Tolling (LPT) as captured by the Authority’s photo-‐monitoring system. Customers at other locations will continue to pay as they currently do with either their electronic pay transponders or cash. Based on the Authority’s evaluation of the AET project at Elm/Peoria, the Authority may convert more interchanges and/or turnpikes to AET at later dates. Future expansion of the OTA AET system may require the LPT operations to be located in Oklahoma. In the event that OTA decides that an expanded operation is required to be in Oklahoma, the OTA may negotiate with the LPT Processor for continued services at that time, or proceed with a new procurement.

Proposers are directed to Attachment 1 Scope of Services and Functional Requirements. The Proposer shall complete the Requirements Traceability Matrix provided in Appendix A to ensure all services as stated can be provided. Additional services or concepts may be added to your proposal, but the Authority may exclude such concepts or services at its discretion.

Proposers are directed to Appendix D for current OTA statistics. This is provided for information purposes only.


4

4. CONTRACT TERM

The initial term of this Contract is 3 years. This includes the design, development, testing and implementation phases. In addition, this Contract has two options to renew for up to one year each. These options are to be exercised at the discretion of the OTA under the same terms and conditions of the original contract.

5. INSTRUCTIONS TO PROPOSERS

Proposals submitted must be in strict compliance with the RFP. Failure to comply with all provisions may result in disqualification.

5.1 Mandatory Pre-‐Proposal Meeting

Proposers are required to participate in a mandatory pre-‐proposal meeting via teleconference. The meeting is tentatively scheduled for July 1st at 10:00 a.m. Central Daylight Time. Attendance of the pre-‐proposal meeting is mandatory in order to be included in the proposal evaluation process. For specific details of the meeting, contact Glen Branscum by email at [email protected].

5.2 Written Questions

Proposers should submit written questions regarding this procurement by email to [email protected] and [email protected]. All emails should reference RFP #15-‐002.

5.3 Oral Presentation

The Authority and its representatives, at its sole discretion, may interview proposers. Presentation format, time limits, materials requested, etc., shall be sent to Proposers with whom interviews are deemed appropriate. The Authority reserves the right to select a preferred Proposer without conducting interviews.

5.4 Best And Final Offer

Proposers may be invited to provide a Best and Final Offer (BAFO).

5.5 Proposal Submittal Requirements

In submitting a proposal, each proposer acknowledges that the Authority shall not be liable for any costs incurred therewith or in connection with costs incurred by any proposer. This RFP does not commit the Authority to award a contract; the Authority may accept or reject in whole or in part any proposal without limitation.

Proposers must submit 10 hard copies and 2 electronic versions on USB drives of their response to this RFP no later than 12:00 p.m., Central Daylight Time, July 24, 2015 to:

Oklahoma Turnpike Authority Attention: Dwight Brown Oklahoma Turnpike Authority 2401 NW 23rd Street Suite 2B-‐1


5

Oklahoma City, OK 73107 PROPOSAL DUE DATE: 12:00 p.m. Central Daylight Time, July 24, 2015

Late proposals will not be considered and shall be returned unopened. Responses to this RFP must be received by the due date and time stated above to be included in the evaluation process. Telephone, facsimile and email proposals will not be accepted. All correspondence in relation to this proposal and the contract shall be written in the English language. All measurements should be submitted in U.S. customary units. Bids will open immediately after the closing time.

The Proposal shall adhere to a combined 150-‐page limit (75 double-‐sided sheets), 12 font, standard margins, except as noted. The contents of the exhibits, required forms and resumes shall not count toward the page limit. Tabbed dividers within paper copies of the Proposal shall not count toward the total page limit.

Each page must include a page number, number of total pages, and identify the Proposer in the page footer.

Each package containing material that the Proposer wishes to be considered as part of the proposal must be sealed with a self-‐adhesive label marked “Sealed Proposal” (included in RFP mailing). The provided bid notification sticker should be affixed to the lower left front of the mailing envelope. This bid notification sticker notifies the Authority mailroom to not open the envelope, as a sealed bid is enclosed. Failure to use these labels may result in the inadvertent opening of the package and may cause the proposal to be rejected.

Requests for further information or questions regarding this RFP should be addressed, in writing, to the individual listed below. Any oral communication will be considered non-‐official and non-‐binding. Respondents should rely only on written statements issued by the individual listed below.

Information Requests and Questions Oklahoma Turnpike Authority ATTN: Glen Branscum 2401 NW 23rd Street Suite 2B-‐1 Oklahoma City, OK 73107 Telephone: 405.936.3640 E-‐mail: [email protected]

5.6 Modification and Withdrawal of Proposal

The Proposer may, without prejudice, modify or withdraw his or her proposal by written request, provided that the Authority receives the request prior to the proposal due date and time. Following withdrawal of the proposal, the Proposer may submit a new proposal provided that such new proposal will be received on or before the proposal due date and time.

The Authority may modify any provision(s) or part(s) of the RFP at any time prior to the proposal closing date and time.


6

5.7 Authority Policy

In accordance with the Authority’s policy, all qualified Proposers are entitled to receive equal opportunities. The offering of gifts, entertainment, payments, loans or other favors for the purpose of being placed on the Proposers list, to obtain a contract, or to receive favorable treatment under a contract, is prohibited. Furthermore, it is the Authority’s policy that in the event a Proposer or Contractor is found to have offered or given a gift or gratuity to obtain a contract or favorable treatment thereunder, the Proposer involved will be refused further Proposal considerations by all of the Authority’s entities. The Authority may also obtain those remedies available under law and the contract including, but not limited to, termination for default.

Any Proposer that feels it has been unjustly treated may file a written objection within five business days of date of award to Ms. Cheryl O'Rourke, Director of Administrative Services. If a Proposer is not satisfied with the response, they may appeal to Mr. Alan Freeman, Assistant Director, at Oklahoma Turnpike Authority, 2401 NW 23rd Street, Suite 2B-‐1, Oklahoma City, OK 73107.

5.8 Schedule

The following is a tentative time schedule. NOTE: All times are Central Daylight Time (CDT).

Issue Request for Proposal June 23, 2015 Mandatory Pre-‐Proposal Meeting 10 a.m. July 1, 2015 Deadline for submission of written questions 3:00 p.m. July 6, 2015 Final Authority response to Questions 3:00 p.m. July 13, 2015 Proposal Due Date 12:00 p.m. July 24, 2015 Oral Presentations August 5 & 6, 2015 Contract Award August 24, 2015 Notice To Proceed Within 30 days of Contract Award

5.9 Key Dates

Ramp B Construction Completed June 27, 2016 Ramp C Construction Completed October 19, 2016 Start of Production Readiness Test June 29, 2016 Go Live January 4, 2017

6. PROPOSAL FORMAT

The Proposal should include the minimum sections requested below in the order listed. Additional information, if provided, should be separately identified in the Proposal.

6.1 Cover Letter

This section must have a letter of introduction on company letterhead summarizing the proposal and signed by an individual authorized to execute legal documents on behalf of the Proposer. The Proposer must provide the legal


7

name and address of the company responsible for the execution of the Contract; legal form of the company (partnership, corporation, joint venture, etc.); and parent company if the company is a wholly owned subsidiary.

6.2 Table of Contents

This section must contain a comprehensive table of contents of material identified by sequential page numbers and by section reference numbers.

6.3 Understanding of the Project and Ability to Meet All Requirements

The proposal shall address all three parts of this section listed below.

1) Proposer’s understanding of the goals and objectives of the project and its ability to successfully and consistently meet or exceed all of the specified requirements and related performance standards.

2) Proposer’s ability to expand their operations and to update their system software for additional functionality, as requested by OTA.

3) Proposer’s approach to successfully implement and manage the Project:

a. Overall Project Management

b. Risk Management

c. Data and Access Security

d. Change Management and Change Control

e. Training

f. Subcontractor Management

g. Audit

h. Quality Assurance and Quality Control

6.4 Firm’s Qualifications, Experience and Financial Sustainability

This section is designed to establish the bidder as an entity with the ability and experience to complete the work as specified in the RFP. This section should include the following:

a. The firm’s hierarchy, overview of services performed, brief history of the firm, company size and client base.

b. The firm’s recent (within the past 5 years) and relevant experience in the design, development and delivery of projects of similar scope and complexity.

c. The firm’s recent (within the past 5 years) and relevant experience in the operation of a license plate tolling system.


8

d. The firm’s knowledge of relevant technology, software applications, platforms, policies and procedures.

e. A list of ALL clients for which the firm has provided design, development and delivery for an AET or LPT tolling system. Five of these clients shall be clearly designated as references for which similar work has been or is currently being performed. The five references should include names, addresses, email addresses and telephone numbers.

f. The firm’s most current audited annual financial statements.

g. Details of the firms last bankruptcy, if any.

h. Details of any current/pending litigation within the past 5 years.

i. Details of any Defaults or Terminations on contracts within the past 10 years

6.5 Project Team’s Qualifications, Relevant Experience and Organization

This section shall describe the following:

a. The Proposer’s organizational structure, including any subcontractors, during design, development and implementation of this project.

b. The Proposer’s organizational structure, including any subcontractors, during on-‐going operations.

c. A project organization chart, including any subcontractors, which indicates functional areas of responsibility as well as the number of staff by position.

d. The physical location of staff that will be working on this project.

e. The firm’s policy and practices regarding the performance of staff background checks.

f. The proposed project team; including the names, titles, qualifications and relevant experience of the following Key Personnel.

i. Design/development team

1. Project Manager

2. System Design Manager

3. Software Design Lead

4. Test Manager

5. Systems Administrator

ii. On-‐going operations

1. Project Manager


9

2. Operations Manager

3. Call Center Manager

4. Image Processing Manager

5. Finance Manager

6. Quality Assurance/Quality Control Manager

g. Availability and commitment of all Key Personnel to the Project.

6.6 Proposed Project Implementation Schedule

This section shall describe the Proposer’s ability to meet the required Go-‐Live date with a fully developed, successfully tested, LPT system and operation which meets all the requirements of this RFP.

This shall include an initial proposed schedule, including the timing, duration and sequence of activities, to complete to meet the required Go-‐Live date.

6.7 Price Proposal

The proposed pricing shall be submitted using the form provide in Appendix B, Proposal Pricing Matrix.

The Authority desires to obtain price bids that are fair and accurate. Although price will be a factor in selection, it will be balanced by the other criteria given. The ultimate contract may or may not be awarded to the Proposer with the lowest price. The Contract Price shall constitute the full compensation to be paid to the LPT Processor for performance of all requirements in the Scope of Services. As described below, proposed pricing shall be submitted in two phases.

a. Design and Development Phase Pricing – The price for the LPT Design & Development Work shall be bid as lump sum fixed price, and shall be paid in accordance with the following Payment Milestones:

o Mobilization (45 days after NTP) 10%

o Design Document approval 25%

o Successful completion of the Factory Acceptance Test 25%

o Successful Go-‐Live 25%

o Successful completion of the System & Operational Acceptance Test 15%

b. On-‐going Operations Phase Pricing – The price for the LPT on-‐going Operation shall be bid on a unit price basis commencing at Go-‐Live and continuing for the Term of the base contract. The unit price values will be adjusted for the option years by an amount not to exceed the lesser of 3% and the change in the U.S. Bureau of Labor Statistics Consumer Price Index -‐ CPI -‐U, US City Average, All Items less food and energy for the most recent calendar year. In no event, however, will the adjustment be less than 0%.


10

c. The following items will be paid by OTA directly or as a pass through cost with no mark-‐up:

o Postage costs

o Credit/Debit/ACH processing fees

o OTA bank fees

o DMV/3rd party name and address acquisition fees

6.8 Alternate Methodology

All Proposers must submit a Base Proposal that meets all requirements of the Statement of Work (SOW) as specified in this RFP.

In addition to providing a Base Proposal, Proposers may submit an alternate method (or methods) of providing OTA with the required basic functionality but not necessarily in the exact manner as defined in the SOW. This may include alternate system design, processes, procedures or methodology that provide equivalent, better and/or more cost effective operation than achievable under the specifications as stated. Alternate methodology may include system design and/or operations that are currently being used by the Proposer in a similar operation or newly designed functionality/operations. Proposer creativity and innovation is encouraged.

Any alternate methods may be highlighted within the body of the Proposal in the appropriate sections, however a separate list of all proposed alternate methods shall also be provided with the Proposal.

The Proposal must clearly and separately identify any and all deviations from the Base Proposal and describe how each of these changes will achieve substantially equivalent or better value in terms of improved operating efficiency and/or enhanced customer service. Additionally, the Proposal shall indicate the effect of implementation of each item or group of items on the Base Price Proposal. This shall include the price impact to the Design and Development phase, as well as to each Unit Price in the Operational phase, as appropriate.

No alternate methods will be considered unless the Proposer has submitted a complete and responsive Base Proposal that meets all requirements as stated in this RFP. OTA reserves the right to choose all, some or none of any alternate methods submitted.

6.9 Evidence of Insurability/Insurance/Applicable License

All bidders shall submit evidence of required insurance. Insurance requirements are detailed in the General Conditions section.

6.10 Bid Bond

A bid bond is required in the amount of 5% of the proposed fixed Design and Development Phase pricing (see Section 6.7 a.). The bid bond is to accompany your submitted bid proposal. Further details on the bid bond are listed in the General Conditions section.


11

7. Evaluation Process and Selection Criteria

The Authority’s intention is to procure the most cost-‐effective, yet comprehensive and professional services available. Proposals will be evaluated based on relevant factors, including the following:

o Understanding of the Project and Ability to Meet All Requirements – 30%

o Firm’s Qualifications, Experience and Financial Sustainability – 20%

o Project’s Team Qualifications, Relevant Experience and Organization – 20%

o Proposed Project Implementation Schedule – 5%

o Price – 25%

If a firm submits both a Base Proposal and alternative methodologies, each will be evaluated separately.

Should the Authority seek clarification or further information from the Proposer during the Proposal evaluation period, the Proposer will be expected to provide all assistance to the Authority during this period, free of charge, to enable the Authority to evaluate the Proposal fully.

8. Validity of Proposal

It is expected that a Proposal shall be accepted, or all Proposals rejected, within 30 days after the Proposal closing date. The Proposals submitted shall be valid for a minimum period of one hundred eighty days (180) after receipt. No work shall be performed in connection with the SOW until the Contract has been fully executed, delivered, and a Notice to Proceed issued.

9. Notice of Award

It is anticipated that a Proposer will be selected within two to four weeks of the Proposal due date. Discussions with the preferred Proposer shall begin immediately upon selection and may culminate in an executed Contract. Unsuccessful Proposers shall be notified of the Contract Award.

The Contractor shall begin work on the date specified in the Notice to Proceed. The Authority will issue the Notice to Proceed within 30 days of execution of the Contract and receipt of all required bonds and insurance.

10. General Conditions

10.1 Taxes

The Proposer/Contractor must provide a tax-‐payer identification number to the Authority. Except to the extent expressly provided to the contrary elsewhere in this Contract, the Contractor shall pay when due all state, and federal sales and use taxes, excise taxes, duties and all other governmental fees and taxes or charges of whatever nature applicable to the performance of the work and this Contract. In other words, the Contractor is responsible for paying all taxes on purchases made to fulfill this contract; these taxes cannot be passed to the Authority as taxes. The Authority is tax exempt.


12

10.2 Confidentiality Agreement

The Contractor agrees that the Contractor, and its employees, agents, and subcontractors will hold confidential and not divulge to third parties without the written consent of the Authority any information obtained by the Contractor from or through the Authority in connection with the Contractor’s performance of this Contract, unless (a) the information was known to the Contractor prior to obtaining same from the Authority and was not obtained under a secrecy obligation to the Authority pursuant to the prior contract; or (b) the information was at the time of disclosure to the Contractor, or thereafter becomes, part of the public domain but not as a result of fault or an unauthorized disclosure of the Contractor or its employees, agents or subcontractors; or (c) the information was obtained by the Contractor from a third party who did not receive the same, directly or indirectly, from the Authority and who had, to the Contractor’s knowledge and belief, the right to disclose the same.

10.3 Independent Contractor

Nothing in this Contract shall be deemed to constitute the Contractor or any of the Contractor’s employees or agents to the agent, representative or employee of the Authority. The Contractor shall be an independent Contractor and shall have responsibility for and control over the details and means for performing the work and shall be subject to the directions of the Authority only with respect to the scope and general results required.

10.4 Assignment

The Contractor shall not assign this Contract wholly or in part, voluntarily, by operation of law, or otherwise without first obtaining the written consent of the Authority. Any assignment of this Contract in violation of the foregoing shall be, at the option of the Authority, void. Subject to the foregoing, the provisions of this Contract shall extend to the benefit of and be binding upon the successors and assigns of the parties hereto.

10.5 Termination at the Authority’s Option

The Authority shall have the right at any time, with or without cause, to terminate further performance of the work by written notice to the Contractor specifying the date of termination. On the date of such termination stated in said notice, the Contractor shall discontinue performance of the work and shall preserve work in progress and completed work, pending the Authority’s instructions, and shall turn over such work in accordance with the Authority’s instructions.

If the Contractor has fully and completely performed all obligations under this Contract up to the date of termination, the Contractor shall recover from the Authority as complete and full settlement for such termination actual cost necessarily incurred in effecting the termination; less all amounts previously paid to the Contractor for the work.

10.6 Indemnity

The Contractor has the absolute and entire responsibility and liability for all damage, loss of injury of any kind, direct or indirect, to any person (including death) or property (except as otherwise provided in the Contract) arising out of or in any manner based on the performance by Contractor under the Contract, or caused by or resulting from the performance of any work on or relating to the Project. Contractor shall, to the fullest extent permitted by law,


13

indemnify and hold harmless the Authority against all losses, claims, damage, expenses (including attorneys’ fees and costs) and liabilities sustained or incurred by the Authority by reason of any act, omission, conduct, negligence or default by Contractor or subcontractor or their respective employees and agents. Excepts as may be otherwise provided by applicable law of any Governmental Authority, the Authority’s right to indemnification shall not be impaired or diminished by any act, omission, misconduct, negligence or default (other than gross negligence or willful misconduct) of the Authority or any employee or agent of the Authority who contributed or may be alleged to have contributed thereto.

10.7 Publicity

The Contractor agrees to make no news release not to issue any advertising pertaining to work or this Contract without first obtaining the written approval of the Authority.

10.8 Insurance

For the duration of the contract, the Contractor shall at its sole cost, obtain and maintain in force the contract insurance of the following types, with limits not less than those set forth below.

• Workers Compensation Insurance, including occupational illness or disease coverage, in accordance with the laws of the nation, state, territory or province having jurisdiction over the Contractor’s employees and Employer’s liability insurance with a minimum limit of $1,000,000 each accident, $1,000,000 disease-‐policy limit and $1,000,000 disease-‐each employee. The Contractor shall not utilize occupational accident or health insurance policies, or the equivalent, in lieu of mandatory Workers’ Compensation Insurance, or otherwise attempt to opt out of the statutory Workers’ Compensation system.

• Automobile Liability Insurance covering use of all owned, non-‐owned and hired automobiles with a minimum combined single limit of liability for bodily injury and property damage of $1,000,000 per occurrence. This policy shall be endorsed to name the Authority, including respective affiliates, directors, and employees, as additional insured.

• Commercial General Liability Insurance (“Occurrence Form”) with a minimum combined single limit of liability of $1,000,000 each occurrence for bodily injury and property damage; with a minimum limit of liability of $1,000,000 each person for personal advertising injury liability; and a minimum limit of liability of $1,000,000 each occurrence for products/completed operations liability. Such policy shall have a general aggregate limit of not less than $2,000,000. The products/completed operations liability coverage shall be maintained in full force and effect for not less than three years following completion of the Contractor’s services. The policy shall be endorsed to name the Authority, including respective affiliates, directors and employees, as additional insured. Such endorsement shall be made upon ISO Endorsement CG 20 10 11 85, “Additional Insured – the Authority’s, Lessees or the Contractors (Form B).”

• Professional Liability (Errors & Omissions) Insurance in an amount not less than $1,000,000 per occurrence, for damages caused by any act or omission of the Contractor, or of any other person for whose acts or omissions the Contractor is legally responsible, arising out of the performance of services in a professional capacity. If the Contractor should terminate such coverage at any time before three (3) years after


14

acceptance or termination of the Contractor’s work, the Contractor shall obtain extended reporting period coverage (“tail cover”), for a period of not less than three (3) years from the Contractor’s last services.

10.9 Bonds

The bid bond may be in the form of a bond or a cashier’s check. The cashier’s check or bond must be payable to the Oklahoma Turnpike Authority. Failure to provide such a bond at the time specified will result in the proposal not being considered. The bond shall be valid for a minimum of 90 days from the proposal date. Withdrawal of the proposal without authorization or failure to successfully execute a contract within 30 days of the Notice to Proceed will result in forfeiture of the proposal bond. The awarded Contractor will be required to provide a default bond, performance bond and a statutory payment bond in the amount of their proposal; see Appendix C. These bonds are required at the time the contract is signed. There is no requirement for these forms to be completed or submitted with the proposal. The surety selected by the Proposer must be acceptable to the Authority. Minimum requirements are:

• Licensed to conduct business in the State of Oklahoma; and

• Names in the current list of “Companies Holding Certificates of Authority as Acceptable Sureties on Federal bonds and as Acceptable Reinsuring Companies” as published annually in Circular 570 by the U.S. Department of Treasury.

10.10 Escrow

Any and all Intellectual Property shall be placed in an escrow ("Intellectual Property Escrow") account in the event that second source availability is no longer possible. The AUTHORITY and CONTRACTOR acknowledge that the CONTRACTOR and Third Parties that supply software, Source Code, or other Intellectual Property may not wish to deliver the Intellectual Property directly to the AUTHORITY and that the CONTRACTOR and/or Third Parties desire to implement measures to protect such information from public disclosure to the extent permitted under applicable Law. CONTRACTOR further acknowledges that the AUTHORITY nevertheless must be ensured access to such Intellectual Property at any time, and must be assured that the Intellectual Property is released and delivered to the AUTHORITY immediately.

The CONTRACTOR shall deposit the Intellectual Property with a neutral trustee. The CONTRACTOR shall select, subject to the AUTHORITY’s prior approval, an escrow company or other neutral custodian ("Escrow Agent") engaged in the business of receiving and maintaining escrows in the metropolitan Oklahoma City area, or in another location the Parties agree to in writing, of Source Code or other Intellectual Property, and establish an Intellectual Property Escrow with the Escrow Agent in such location on terms and conditions agreed upon by both Parties as for the deposit, retention and upkeep of Source Code, Source Code Documentation, build tools, operating system and other software necessary to configure and build the software and/or other Intellectual Property and related documentation. Intellectual Property Escrow also may include Third Parties as parties and may include deposit of their Intellectual Property. The CONTRACTOR shall be responsible for the fees and costs of the Escrow Agent.

License Plate Tolling System application software shall be fully documented, as set forth elsewhere in this document, such that the AUTHORITY shall possess sufficient information to make future software changes with its own resources, other software specialists or the CONTRACTOR Software engineers. The AUTHORITY has no intention of


15

marketing the License Plate Tolling System software to other parties and the AUTHORITY, and its Representatives, shall endeavor to maintain confidentiality of the developed software and software documentation, except as needed to effect changes, expansions or improvements to the License Plate Tolling System. Developed software shall mean the computer software and executable code (“Source Code”) developed specifically for this project.

The intention of these provisions is to ensure that the AUTHORITY will not have to rely exclusively on the CONTRACTOR to provide future software modifications after the License Plate Tolling System is accepted. The AUTHORITY may elect to use the CONTRACTOR for such services, at the AUTHORITY’S option.

The CONTRACTOR shall make such delivery to the escrow account not later than, for pre-‐existing Source Code and Source Code Documentation, immediately upon execution of this Contract or, if provided by a License Plate Tolling Vendor, execution of the relevant Contract; for Source Code and Source Code Documentation incorporated into or used on or for the Project, prior to the applicable project completing the System & Operational Acceptance Test; for any Technology Enhancement, update, upgrade or correction of Source Code and Source Code Documentation incorporated into or used on or for the Project or any portion thereof, not later than 15 days after the end of the calendar quarter in which it is first incorporated or used in any Project; and for any other Intellectual Property, on the Effective Date if it exists as of such, and otherwise within 15 days after the end of the calendar quarter in which it is first incorporated or used in connection with the Project or the Work.

The AUTHORITY shall be a signatory of the escrow agreement and each Intellectual Property Escrow with direct rights of enforcement against the CONTRACTOR and the escrow agent. Each escrow agreement shall provide that any amendment or supplement to such escrow agreement shall be subject to the AUTHORITY’s prior written approval in its sole discretion.

The Intellectual Property Escrows shall survive expiration or earlier termination of this Contract regardless of the reason, until such time as both Parties agree, in their respective sole discretion, that the Intellectual Property contained therein is of no further use or benefit to the Project.

10.1 Revenue Loss

The LPT Processor acknowledges that its performance under this Agreement is critical to the operations and revenue collection of the Authority.

In the event of any failure of the License Plate Tolling Processor’s Systems (excluding any such failure to the extent caused by force majeure) or any actions by the LPT Processor that result in revenue loss, the LPT Processor shall be liable for losses incurred by the Authority as a result thereof, including lost toll revenues. In the event of any such failure, the LPT Processor shall take appropriate measures to correct the deficiency that caused the problem. With respect to any failure that results in inability of the License Plate Tolling Processor to determine the amount of lost revenue, the parties hereby stipulate that lost revenues shall be calculated based on a comparison of revenues received during the period in question and revenues received during a comparable prior period determined by the Authority.

The Authority may choose, in its sole discretion, to recover such lost revenue from the LPT Processor by deducting such amounts from payments otherwise due and owing from the Authority to the LPT Processor. The LPT Processor


16

may be required, at the Authority’s sole discretion, to pay an additional 10% penalty to the Authority for any actual damages described in this Section.

10.2 Public Availability to RFP Records

Copies of the proposals will be available for public inspection, (after award has been made) under supervision of the Purchasing Department, in the General Administration Services Division from 7:30 A.M. to 4:30 P.M. Monday through Friday at the Oklahoma Turnpike Authority, Oklahoma Turnpike Authority, 2401 NW 23rd Street, Suite 2B-‐1 Oklahoma City, OK 73107. 10.3 Audit of Records

In the event a contractual agreement is created pursuant to this RFP, the contract must contain the following audit clause.

[Firm] shall permit OTA designated personnel the right to examine [firm’s] relevant financial and operational records related to this agreement. OTA shall have the right to audit and verify statements submitted by [firm] pursuant to this agreement. [Firm] shall retain these records for a period of three years after the final payment under this agreement or until all pending matters are closed, whichever is later. OTA reserves the right to dispute and receive credit for any costs which an audit may prove to be inappropriate.

10.4 Other Terms & Conditions

The Authority reserves the right to reject any or all proposals or to cancel this solicitation at any time.

The Authority reserves the right to waive minor technicalities in this RFP.

17

OKLAHOMA TURNPIKE AUTHORITY

NON-‐COLLUSION BIDDING CERTIFICATION

___________________

STATE OF OKLAHOMA ) ) SS

COUNTY________________)

A. For purposes of competitive bids, I certify:

1. I am the duly authorized agent of ___________________________________, the bidder submitting the competitive bid which is attached to this statement, for the purpose of certifying the facts pertaining to the existence of collusion among bidders and between bidders and state officials or employees, as well as facts pertaining to the giving or offering of things of value to government personnel in return for special consideration in the letting of any contract pursuant to the bid to which this statement is attached;

2. I am fully aware of the facts and circumstances surrounding the making of the bid to which this statement is attached and has been personally and directly involved in the proceedings leading to the submission of such bid; and

3. Neither the bidder nor anyone subject to the bidder’s direction or control has been a party to the following: a. Any collusion among bidders in restraint of freedom of competition by agreement to bid at a fixed price

or to refrain from bidding; b. Any collusion with any state official or employee as to quantity, quality or price in the prospective

contract, or as to any other terms of such prospective contract; and c. Any discussions between bidders and any state official concerning exchange of money or other thing of

value for special consideration in the letting of a contract.

B. I certify, if awarded the contract, whether competitively bid or not, that neither the Contractors nor anyone subject to the Contractor’s direction or control has paid, given, or donated or agreed to pay, give, or donate to any officer or employee of the State of Oklahoma any money or other thing of value, either directly or indirectly, in procuring the contract to which this statement is attached.

Certified this _______ day of __________________, 20____.

_________________________________

(Signature)

_________________________________ ________________________________

(Print Name) (Position in the Company)

3/2014

Attachment 1 – Scope of Services & Functional Requirements Oklahoma Turnpike Authority

Page 1 of 111

Oklahoma Turnpike Authority License Plate Tolling Processor

Request For Proposal

Scope of Services and Functional Requirements

June 2015


Page 2 of 111

TABLE OF CONTENTS

PROJECT OVERVIEW ................................................................................................................ 7

I. GENERAL REQUIREMENTS .............................................................................................. 7 1 PROJECT OVERVIEW ....................................................................................................................................................7

Summary of Scope .............................................................................................................................................7 1.1

Quality Assurance & Quality Control ................................................................................................................7 1.2

Customer Satisfaction Surveys ..........................................................................................................................9 1.3

Existing OTA Contracts .....................................................................................................................................9 1.4

2 PROJECT MANAGEMENT .............................................................................................................................................9 General Project Management Requirements .....................................................................................................9 2.1

3 STAFFING ..................................................................................................................................................................10 Staffing Plans - Team Organization .................................................................................................................10 3.1

4 DOCUMENTATION REQUIREMENTS ...........................................................................................................................11 General Documentation Requirements ............................................................................................................11 4.1

Deliverable Management .................................................................................................................................11 4.2

Document Reviews ..........................................................................................................................................12 4.3

Submittal Approval ..........................................................................................................................................12 4.4

5 PROJECT COMMUNICATIONS .....................................................................................................................................12 Project Scope ...................................................................................................................................................12 5.1

Meetings ...........................................................................................................................................................13 5.2

Status Meetings – Design and Development ...................................................................................................13 5.3

Status Meetings – Operations ..........................................................................................................................14 5.4

6 PROJECT SCHEDULE ..................................................................................................................................................14 General Project Schedule Requirements ..........................................................................................................14 6.1

Schedule Delays ...............................................................................................................................................15 6.2

Schedule Revisions ..........................................................................................................................................15 6.3

7 DATA RETENTION AND DESTRUCTION ......................................................................................................................16 General Data Retention and Destruction Requirements ..................................................................................16 7.1

Specific Data Retention and Destruction Requirements ..................................................................................16 7.2

8 SUCCESSION ..............................................................................................................................................................17 Succession Plan ................................................................................................................................................17 8.1

Succession Procedures .....................................................................................................................................18 8.2

II. DESIGN, DEVELOPMENT AND TESTING ..................................................................... 20 9 SYSTEM DEVELOPMENT ............................................................................................................................................20

System Design and Development Plan (SDDP) ..............................................................................................20 9.1


Page 3 of 111

Requirements Review Workshops ...................................................................................................................21 9.2

Requirements Traceability Matrix (RTM) .......................................................................................................21 9.3

10 DESIGN ....................................................................................................................................................................21 General Design Requirements .......................................................................................................................21 10.1

Preliminary Design Document and Review ...................................................................................................22 10.2

System Design Document (SDD) and Review ..............................................................................................22 10.3

11 TESTING REQUIREMENTS ........................................................................................................................................24 General Testing Requirements .......................................................................................................................24 11.1

Master Test Plan (MTP) .................................................................................................................................26 11.2

General Test Plan Requirements ....................................................................................................................28 11.3

Factory Acceptance Test (FAT) .....................................................................................................................28 11.4

Installation and Interface Test ........................................................................................................................29 11.5

Disaster Recovery Test ..................................................................................................................................30 11.6

Production Readiness Test .............................................................................................................................30 11.7

System & Operational Acceptance Test ........................................................................................................32 11.8

12 GO-LIVE ..................................................................................................................................................................32 General Go-Live Requirements .....................................................................................................................32 12.1

III. LICENSE PLATE TOLLING OPERATIONAL REQUIREMENTS .............................. 33 13 TECHNICAL REQUIREMENTS ...................................................................................................................................33

System Requirements .....................................................................................................................................33 13.1

LPT System Data Center Requirements ........................................................................................................33 13.1

LPT System Requirements ............................................................................................................................34 13.2

LPT System Operating System and Software ................................................................................................35 13.3

LPT System Dashboard .................................................................................................................................35 13.4

Database Requirements ..................................................................................................................................36 13.5

LPT System End User Requirements ............................................................................................................38 13.1

14 SECURITY ................................................................................................................................................................38 General Security Requirement .......................................................................................................................38 14.1

Access Security ..............................................................................................................................................38 14.2

Data Security ..................................................................................................................................................39 14.3

Payment Card Industry Data Security Standard (PCI DSS) ..........................................................................40 14.4

15 SYSTEM ADMINISTRATION & MAINTENANCE .........................................................................................................41 General System Administration & Maintenance Requirements ....................................................................41 15.1

16 DISASTER RECOVERY/BUSINESS CONTINUITY ........................................................................................................41 General Disaster Recovery/Business Continuity Requirements ....................................................................41 16.1

17 DOCUMENTATION ...................................................................................................................................................44 Policies and Procedures Review ....................................................................................................................44 17.1


Page 4 of 111

Manuals ..........................................................................................................................................................45 17.2

18 ADMINISTRATIVE REQUIREMENTS ..........................................................................................................................46 General Administrative Requirements ...........................................................................................................46 18.1

Staffing ...........................................................................................................................................................46 18.2

Training ..........................................................................................................................................................47 18.3

Document Control ..........................................................................................................................................48 18.4

Customer Information and Privacy ................................................................................................................48 18.5

Agency Access ...............................................................................................................................................49 18.6

19 LPT PHYSICAL LOCATION .......................................................................................................................................50 General LPT Physical location Requirements ...............................................................................................50 19.1

Physical Security ............................................................................................................................................51 19.2

Operating Hours .............................................................................................................................................52 19.3

20 TRANSACTION PROCESSING ....................................................................................................................................52 General Transaction Processing .....................................................................................................................52 20.1

Image Review ................................................................................................................................................52 20.2

LPT Watch List ..............................................................................................................................................53 20.3

PIKEPASS Account Match Processing .........................................................................................................54 20.4

Name and Address Acquisition via Registered Owner of Vehicle (ROV) Lookup ......................................54 20.5

LPT Transaction Processing ..........................................................................................................................55 20.6

LPT Invoice Account Establishment .............................................................................................................56 20.7

21 INVOICE GENERATION AND ESCALATION ...............................................................................................................56 Invoice Generation and Issuance ...................................................................................................................56 21.1

Invoice Issuance Suppression ........................................................................................................................57 21.2

Invoice Layout Requirements ........................................................................................................................57 21.3

Customer Fees ................................................................................................................................................59 21.4

Invoice Escalation ..........................................................................................................................................59 21.5

22 VIOLATION PROCESSING .........................................................................................................................................65 Violation Processing ......................................................................................................................................65 22.1

Violation Notice Generation and Issuance ....................................................................................................65 22.2

Violation Notices Tracking and Resolution ...................................................................................................66 22.3

Vehicle Registration Stop Flags .....................................................................................................................67 22.4

Collection Agency .........................................................................................................................................67 22.5

23 PAYMENT PROCESSING ...........................................................................................................................................68 General Payment Processing Requirements ..................................................................................................68 23.1

24 ACCOUNT MAINTENANCE AND MANAGEMENT .......................................................................................................69 Customer Information and Correspondence ..................................................................................................69 24.1

General Account Management ......................................................................................................................69 24.2


Page 5 of 111

Disputes and Adjustments ..............................................................................................................................70 24.3

Toll/Fee Dismissal .........................................................................................................................................70 24.4

Transfer of Responsibility (TOR) ..................................................................................................................70 24.5

UPA Conversion to PIKEPASS .....................................................................................................................71 24.6

25 LPT SYSTEM INTERFACES .......................................................................................................................................71 External Interfaces .........................................................................................................................................71 25.1

Host Interface .................................................................................................................................................72 25.2

File Exchanges ...............................................................................................................................................72 25.3

Transaction Reconciliation ............................................................................................................................73 25.4

PIKEPASS Account Match Lookups ............................................................................................................73 25.5

Oklahoma License Plate Lookups .................................................................................................................74 25.6

Texas License Plate Lookups .........................................................................................................................74 25.7

CVIEW License Plate Lookups .....................................................................................................................74 25.8

Hot Lists .........................................................................................................................................................75 25.9

Oklahoma Tax Commission ........................................................................................................................75 25.10

Third Party Interfaces ..................................................................................................................................75 25.11

26 MAIL PROCESSING ..................................................................................................................................................76 General Mail Processing Requirements .........................................................................................................76 26.1

Incoming Mail Processing .............................................................................................................................76 26.2

Outgoing Mail Processing ..............................................................................................................................77 26.3

27 CUSTOMER COMMUNICATIONS & MATERIALS .......................................................................................................78 Customer Communications ............................................................................................................................78 27.1

Email ..............................................................................................................................................................78 27.2

Social Media ..................................................................................................................................................79 27.3

IVR System ....................................................................................................................................................79 27.4

Call Center .....................................................................................................................................................80 27.5

28 WEBSITE .................................................................................................................................................................81 Website Requirements ...................................................................................................................................81 28.1

Website Account Management ......................................................................................................................82 28.2

Website Services ............................................................................................................................................82 28.3

Website Security ............................................................................................................................................83 28.4

29 PAYMENT PROCESSING ...........................................................................................................................................84 General Payment Processing Requirements ..................................................................................................84 29.1

Credit/Debit Card and ACH Processing ........................................................................................................85 29.2

Cash and Checks Processing ..........................................................................................................................87 29.3

Refunds ..........................................................................................................................................................88 29.4

30 CASH PAYMENT NETWORK .....................................................................................................................................88


Page 6 of 111

General Cash Payment Location Requirements ............................................................................................88 30.1

CPN Payments ...............................................................................................................................................89 30.2

CPN Transaction Fees ....................................................................................................................................89 30.3

CPN Receipts .................................................................................................................................................90 30.4

LPT and CPN Interface ..................................................................................................................................90 30.5

CPN Merchant Locations ...............................................................................................................................90 30.6

CPN Merchant Locator ..................................................................................................................................91 30.7

CPN Reports ..................................................................................................................................................91 30.8

CPN Customer Service Requirements ...........................................................................................................92 30.9

31 FINANCIAL RESPONSIBILITIES .................................................................................................................................93 General Financial Responsibilities Requirements .........................................................................................93 31.1

Financial Reconciliation ................................................................................................................................93 31.2

32 AUDITING ................................................................................................................................................................95 General Audit Requirements ..........................................................................................................................95 32.1

Internal Controls ............................................................................................................................................95 32.2

33 REPORTING ..............................................................................................................................................................96 General Reporting Requirements ...................................................................................................................96 33.1

Ad Hoc Reports ..............................................................................................................................................98 33.2

Research Screens ...........................................................................................................................................99 33.3

Specific Report Requirements .......................................................................................................................99 33.4

34 PERFORMANCE STANDARDS .................................................................................................................................107 General Performance Standard Requirements .............................................................................................107 34.1

Example Performance Standard Adjustment (Percentage Method) ............................................................110 34.2

LIST OF TABLES Table 1: Testing Summary ..................................................................................................................................................27 Table 2: Invoice Escalation Process ...................................................................................................................................60

Page 7 of 111

Project Overview

This Scope of Services for the License Plate Tolling (LPT) Processor consists of three major areas as defined below:

• General Requirements – The general requirements of the LPT provider are described in this section.

• Design and Development – Design, development and implementation of all Software, hardware, processes, and operational requirements necessary as defined in this Scope of Services and as identified through the design process to support the OTA LPT operation.

• License Plate Tolling Operations – Perform full and complete service of the on-going operation of the OTA LPT operation related to: o Unregistered LPT Account Establishment

o Image Review o Transaction Processing

o Payment Processing o Customer Service

o Call Center

I. General Requirements

1 Project Overview

Summary of Scope 1.1

1.1.1 The LPT Processor shall provide a comprehensive, fully tested and integrated, “turn-key” solution that shall meet or exceed all requirements herein and shall be responsible for all activities related to establishment, implementation and on-going operation of the OTA LPT operation as described in this document.

1.1.2 The LPT Processor shall work cooperatively with OTA for such things as PIKEPASS integration testing and ongoing operations.

Quality Assurance & Quality Control 1.2

1.2.1 The LPT Processor shall establish, implement and maintain a Quality Assurance (QA) and Quality Control (QC) program throughout all phases of the Contract.

Page 8 of 111

1.2.2 The LPT Processor shall establish and implement procedures to identify, define, track and report to OTA all items that could adversely impact the success of the Project and/or any areas that may impact customers or their perception of the Project and/or OTA. These items include, without limitation, call center performance, timely and accurate issuance of statements and invoices, transaction processing, image review, all aspects of customer service (including call quality and customer satisfaction), meeting milestone dates, reliability and accuracy of data, and the integrity of reports and financial Transactions.

1.2.3 The LPT Processor shall ensure that all QA/QC requirements are met by all of its Subcontractors and vendors.

1.2.4 The LPT Processor shall prevent, detect, and correct deviations from any requirement, including by Subcontractors, and report such items to OTA.

1.2.5 The LPT Processor’s QA/QC program shall address all staffing, equipment, methods, procedures, activities, and schedule requirements relating to QA/QC activities.

1.2.6 The LPT Processor’s QA/QC program shall ensure the accuracy and timeliness of the issuance of statements, invoices and general correspondence.

1.2.7 The LPT Processor’s QA/QC program shall continually evaluate LPT operations for accuracy, completeness, and efficiency.

1.2.8 The LPT Processor shall establish procedures to ensure that all requirements of the Contract are performed completely, accurately and in a timely manner and correct any area of performance that is below standard.

1.2.9 The LPT Processor’s QA/QC program shall include reasonableness checks that evaluate accuracy and efficiency such as analyses of abnormal deviations in quantity, volume, dollar amounts, elapsed time, and staff hours.

1.2.10 The LPT Processor shall implement changes and/or corrective action upon error identification during the QA/QC processes.

1.2.11 The LPT Processor shall review a random sample of invoices from every batch, automatically generated by the system, for accuracy and quality. The following are checked:

• Issued date;

• Due date;

• Customer address;

• License plate number; and

• Toll amounts.

Page 9 of 111

Customer Satisfaction Surveys 1.3

1.3.1 The LPT Processor shall establish a process to perform customer satisfaction surveys via the IVR and mail.

1.3.2 The LPT Processor shall work with OTA to finalize the content and questions included in the customer satisfaction surveys.

1.3.3 The LPT Processor shall implement the customer satisfaction surveys as directed by OTA, as frequently as annually.

1.3.4 The LPT Processor shall report the results of customer satisfaction surveys to OTA within one week of the conclusion of a survey period.

1.3.5 The LPT Processor shall not include the time customers spend interacting with the customer satisfaction survey in its call time statistics.

Existing OTA Contracts 1.4

OTA has pre-existing contracts for goods and services with certain providers in support of the PIKEPASS operation. These contracts will be carried forward to support the new LPT operation and OTA will pay the costs incurred under these contracts directly or as a direct pass through to OTA of actual cost. 1.4.1 The LPT Processor shall coordinate its Work with the services provided by OTA’s

other contractors. The pre-existing contracts are as follows:

Credit Card Processor – currently TransFund 1.4.1.1

Banking Services – currently Bank of Oklahoma 1.4.1.2

Collections Services – currently Kansas Counselors, Inc. 1.4.1.3

DMV ROV Look-up – currently American Traffic Solutions (optional) 1.4.1.4

2 Project Management

General Project Management Requirements 2.1

2.1.1 The LPT Processor shall manage the planning and execution of all aspects of the requirements in this document.

2.1.2 The LPT Processor shall provide project management throughout the term of the contract.

2.1.3 The LPT Processor shall coordinate its activities with OTA and other agencies, as required.

Page 10 of 111

2.1.4 The LPT Processor shall execute the Project in accordance with all required Plans.

2.1.5 The LPT Processor shall deliver monthly and quarterly status reports providing review and analysis of the LPT operation.

2.1.6 The LPT Processor shall schedule and meet with OTA Management on a monthly basis to present and discuss monthly and quarterly status reports.

2.1.7 The LPT Processor shall provide a schedule of services to OTA, as needed, for deployment of new Software, LPT System enhancements, bug fixes, hardware upgrades, and any functionality required for security and LPT System vulnerability mitigation.

3 Staffing

Staffing Plans - Team Organization 3.1

3.1.1 The LPT Processor shall develop a detailed Staffing Plan for OTA review and approval in accordance with the Project Schedule.

3.1.2 The Staffing Plan shall address staffing during the Design and Development Phase and during the LPT Operations Phase.

3.1.3 The Staffing Plan shall include, but not be limited to, the following:

A description of the LPT Processor’s Project team organization, reporting 3.1.3.1relationships, key project personnel and team member contact information.

The physical location of all staff. 3.1.3.2

A detailed Project organization chart that is a graphical representation of the 3.1.3.3LPT Processor’s staff hierarchy, including any Subcontractors, and indicates functional areas of responsibility as well as the number of staff by position.

Performance objectives for each work position and how the LPT Processor 3.1.3.4shall continuously monitor personnel performance against these objectives.

Corrective actions for dealing with any unsatisfactory performance. 3.1.3.5

A description of the LPT Processor’s Policies and Procedures regarding the 3.1.3.6selection of qualified staff, the performance of background checks, the assignment of staff to handle sensitive information and compliance with applicable employment regulations.

A description of all Subcontractor relationships and responsibilities. 3.1.3.7

Page 11 of 111

4 Documentation Requirements

General Documentation Requirements 4.1

4.1.1 The LPT Processor shall maintain all documentation related to the LPT design, development and operation as defined in this scope of work.

4.1.2 The LPT Processor shall maintain a soft copy library of current versions of all Project documents in a secure location with web access for all approved members of the OTA Project team.

4.1.3 If changes occur in any aspect of the Project that alters operations, the LPT Processor shall update relevant documentation within one month of that change, unless a specific alternative update schedule is approved by OTA.

4.1.4 The LPT Processor shall back up all soft copy library files at least daily.

4.1.5 The LPT Processor shall maintain all documentation in formats found in the Microsoft Office suite unless otherwise specified by OTA.

4.1.6 The LPT Processor shall make all documentation available to OTA in electronic copy format. Electronic versions shall be in the original format in which the document was created (e.g., Microsoft Word/Excel).

4.1.7 The LPT Processor shall ensure each document produced contains a title sheet, table of contents, list of illustrations (if applicable), revision log, and list of reference drawings (if applicable).

4.1.8 With the exception of the original equipment manufacturer standard documentation (e.g., manuals, catalogs), the LPT Processor shall ensure all documents are formatted to be printed double-sided on 8.5" by 11" sheets and may include 11" by 17" “engineering fold” inserts.

4.1.9 The LPT Processor shall ensure the left-hand margin of the sheets in documents is adequate to ensure binding without encumbering the reading of the material.

4.1.10 The LPT Processor shall ensure all drawings, graphs, plans, charts, and illustrations are produced with computer aided drafting software or other software approved by OTA.

Deliverable Management 4.2

4.2.1 The LPT Processor shall submit all deliverables and work products to OTA for review, comment and approval. OTA reserves the right to reject documents prior to detailed review due to the document’s failure to meet the purpose and intent of the deliverable. In the event a deliverable is rejected, OTA will notify the LPT Processor of the basis for rejection in writing. Rejection of a deliverable shall constitute a delay caused by

Page 12 of 111

the LPT Processor if a completed version of the document is not approved by the document final version approval date in the approved Project Schedule.

Document Reviews 4.3

4.3.1 The LPT Processor shall submit documents for OTA’s review, comment, and approval in accordance with the approved Project Schedule. The schedule shall allow for a minimum of two review/revision cycle iterations, with a 10-Business Day OTA review period for each cycle.

4.3.2 OTA may require additional review time if the LPT Processor submits multiple, simultaneous or overlapping submittals or deliverables in excess of 100 pages.

4.3.3 The LPT Processor shall submit an empty, multi-column comments matrix with each document. OTA will enter its comments into the matrix and the LPT Processor shall track the status of all comments as well as comment responses and resolution for every comment in the matrix.

4.3.4 The LPT Processor shall update the relevant documents to address comments submitted by OTA in sufficient time to maintain the approved Project Schedule.

Submittal Approval 4.4

4.4.1 OTA’s approval of documents shall not relieve or limit the LPT Processor’s responsibility to provide systems and services in full compliance with the Contract.

4.4.2 If and when OTA submits comments, the LPT Processor shall resubmit the documentation and deliverables until such time as OTA accepts the document. Any time required for re-submittal or review of re-submittals shall not be an OTA-Caused Delay.

4.4.3 Deviations from the requirements set forth in this Scope of Services that may be contained within LPT Processor submitted documents, even though the document may be approved by OTA, shall not have the effect of modifying any requirement set forth in the Contract unless such deviations are explicitly disclosed as deviations and OTA expressly acknowledges and approves the deviations. Only formal requests to OTA, from the LPT Processor, for waivers or specification changes that are formally approved by OTA shall modify the requirements set forth in the Contract.

5 Project Communications

Project Scope 5.1

5.1.1 All decisions or directives relating to Project scope, schedule, design, procedures, Business Rules, or policy must be in writing and approved by OTA, in order to be incorporated into the official Contract Documents.

Page 13 of 111

Meetings 5.2

5.2.1 The LPT Processor shall develop meeting agendas for all meetings called by the LPT Processor or requested by OTA.

5.2.2 The LPT Processor shall distribute meeting agendas at least 24 hours in advance of all meetings for OTA approval.

5.2.3 The LPT Processor shall record notes of all meetings and distribute copies of the draft notes to attendees within 3 Business Days of the meeting for review and comment. At a minimum, the LPT Processor shall include the following in all meeting notes:

A complete list of attendees, whether present or on website/phone 5.2.3.1

Descriptions of issues discussed 5.2.3.2

Decision items, if any, shall be summarized at the beginning of all meeting 5.2.3.3note documents

Direction given 5.2.3.4

Open issues 5.2.3.5

Specific action items, including the responsible individual and estimated 5.2.3.6completion dates

Status Meetings – Design and Development 5.3

5.3.1 The LPT Processor shall schedule status meetings, at least monthly, with designated OTA staff throughout the Design and Development phase. Commencing within the first 30 days after Notice To Proceed (NTP) and continuing until Go-Live the LPT Processor shall schedule and conduct monthly status meetings with OTA to review the status of the Design and Development effort.

5.3.2 Commencing within the first 30 days after issuance of NTP and continuing to System Acceptance, the LPT Processor shall submit a Monthly Progress Report.

5.3.3 The LPT Processor shall submit Design & Development - Monthly Progress Reports by the 7th Business Day of each month for the preceding month.

5.3.4 The LPT Processor shall include the following in all Monthly Progress Reports:

Progress for the prior month for all Project activities. 5.3.4.1

Actual start and actual finish dates of work, percentage complete, and days 5.3.4.2remaining for work-in-progress.

Page 14 of 111

All potential delays and problems, if any; actions the LPT Processor is taking 5.3.4.3to address the delays or problems, and their estimated effect on the Project Schedule and overall Project completion.

Electronic copies of the updated Project Schedule. If there are any changes to 5.3.4.4the schedule from the previous Monthly Progress Report the changes shall be highlighted.

Progress on activities requiring coordination with third parties. 5.3.4.5

Deliverables scheduled for submittal in the next reporting period. 5.3.4.6

30-day look-ahead report on all activities scheduled. 5.3.4.7

Status Meetings – Operations 5.4

5.4.1 Commencing within the first 30 days after Go-Live and continuing through the end of the Contract, the LPT Processor shall schedule and conduct monthly status meetings with OTA to inform OTA of the performance of the system and operations, any problems noted and solutions.

5.4.2 Monthly status meetings shall include discussion about customer service call quality, customer satisfaction, performance standards and any related issues.

5.4.3 The LPT Processor shall submit Operations - Monthly Status Report (see Requirement 33.4.37) by the 7th Business Day of each month for the preceding month.

6 Project Schedule

General Project Schedule Requirements 6.1

6.1.1 Within 15 business days after NTP, the LPT Processor shall submit a detailed critical path Project Schedule that supports a Go-Live date, currently set for January 4, 2017. This date is dependent on the completion of construction of the ramps at Elm/Peoria. Construction is tentatively schedule to be completed for the first ramp at the end of June 2016 and in mid-October 2016 for the second ramp.

6.1.2 The Project Schedule shall identify all tasks to be accomplished and related dates from System Design to System & Operational Acceptance.

6.1.3 The Project Schedule shall include deliverable and approval dates for all documents that will be submitted for OTA review and approval.

6.1.4 Once the Project Schedule is approved by OTA, the approved version shall be considered the Baseline Schedule and shall not change without explicit written consent from OTA.

Page 15 of 111

6.1.5 The Project Schedule shall be updated as needed to reflect the current state of the schedule, in addition to showing the Baseline Schedule dates for all tasks.

6.1.6 The Project Schedule shall include all detailed steps that are required to accomplish scheduled Go-Live, including Design, Development and Testing, with related dates.

6.1.7 The LPT Processor shall create a Project Schedule that provides a fully functional LPT operation meeting all requirements in this Scope of Services by the Go-Live date.

6.1.8 Go-Live shall be achieved when all of the following have been completed:

OTA receipt and approval of the all pre Go-Live test reports. 6.1.8.1

OTA receipt and approval of confirmation that the LPT System and software 6.1.8.2escrow deposit contains the current version of all software and materials.

OTA receipt and approval of all Project deliverables. 6.1.8.3

Successful Go-Live in accordance with the OTA approved Go-Live plan. 6.1.8.4

6.1.9 The LPT Processor shall include time for submittal, review and approval of all Project deliverables in the Project Schedule.

6.1.10 Throughout the Term, the LPT Processor shall monitor, and update the Project Schedule whenever changes to the LPT System or operations of a material nature occur, or as directed by OTA.

6.1.11 The LPT Processor shall submit the Project Schedule in Microsoft Project and Adobe PDF formats.

Schedule Delays 6.2

6.2.1 The LPT Processor shall identify and promptly report to OTA all Project Schedule and progress delays during the execution of the Project.

6.2.2 In the event of any Project Schedule delay, the LPT Processor shall take appropriate action to develop a recovery schedule.

6.2.3 The LPT Processor shall submit a recovery schedule immediately following the identification of a Project Schedule delay.

6.2.4 Recovery schedules shall not release the LPT Processor from liability for a delayed schedule.

Schedule Revisions 6.3

6.3.1 The LPT Processor shall submit proposed changes to the Project Schedule along with the reason for the proposed changes for OTA approval as it becomes necessary to modify the Project Schedule.

Page 16 of 111

6.3.2 Until OTA approves in writing any schedule revision, all Project Schedule submittals shall be tracked against the previously approved Baseline Schedule.

6.3.3 Approved schedule changes shall not release the LPT Processor from the original requirements and Contract Deadlines unless explicitly agreed to in writing by OTA.

6.3.4 The LPT Processor shall create a revised schedule, based on approval of a proposed schedule change, and it shall be used as the basis for the subsequent monthly Project Schedule updates and reports.

7 Data Retention and Destruction

For the purposes of this section, Data Retention and Destruction refers to the storage, archiving and destruction of data related to the LPT operation. Data includes both account specific and non-account specific data. Examples of account specific data and records are customer transactions, customer demographic information, vehicle records, scanned correspondence, invoices, violations, account notes, customer license plate images, and customer payment and financial transactions. Examples of non-account specific data and records are accounting and financial reconciliations, reports, performance standard data, images not identified to a specific account and call center statistics. This also includes audit system logs, access logs, audit trails, application logs, data dictionaries and other system generated data.

General Data Retention and Destruction Requirements 7.1

7.1.1 The LPT Operator shall be responsible for the retention, archiving and destruction of data related to the LPT program.

7.1.2 The LPT Operator shall not destroy any data or records without specific approval of OTA, except as necessary in maintaining compliance with PCI standards.

7.1.3 All archival parameters shall be configurable for each type of data.

Specific Data Retention and Destruction Requirements 7.2

7.2.1 All account specific data and records related to open accounts and/or accounts with unpaid amounts shall be available to authorized users via the LPT System for at least 3 years and shall be archived and retrievable throughout the term of the Contract, including any extensions.

7.2.2 All account specific data and records not covered in Requirement 7.2.1 shall be available to authorized users via the LPT System for 2 years, archived and retrievable for an additional 3 years, and then destroyed.

Page 17 of 111

7.2.3 All non-account specific System data and records shall be maintained in the LPT System for 2 years, archived and retrievable for an additional 3 years, and then destroyed.

7.2.4 All non-account specific hard copy documents shall be maintained at the LPT processing location for 2 years, archived and retrievable for an additional 3 years, and then destroyed.

7.2.5 Hard copies of all scanned documents shall be retained for 3 months after being scanned, and then destroyed.

7.2.6 The LPT Processor shall perform all data and document destruction within 3 months after the required retention timeframe is reached.

7.2.7 The LPT System shall be capable of restoring archived data on a temporary basis for research and query purposes.

8 Succession

Succession Plan 8.1

8.1.1 Within 365 days of NTP, the LPT Processor shall prepare and submit a Succession Plan for OTA review and approval.

8.1.2 The Succession Plan shall detail a method for the orderly transfer of LPT operations including knowledge, data, manuals, documents, assets, call routing, licensing and business relationships from the LPT Processor to the successor service provider (“Successor”) or OTA, should the Contract terminate for any reason.

8.1.3 The Succession Plan, when implemented, shall ensure no interruption of LPT operations.

8.1.4 At the specific written direction of OTA, the LPT Processor shall implement, perform and carry out all activities as described in the OTA approved Succession Plan.

8.1.5 The Succession Plan shall include an overview and sequential steps detailing the transfer of each LPT operational area to the Successor or OTA.

8.1.6 The Succession Plan shall include, at a minimum, sections covering operational shut downs and the transfer and/or replacement of:

Physical assets, including a current list of assets and their owners 8.1.6.1

Staffing and organization, including training 8.1.6.2

Product usage and Software licenses, including a current list of licenses 8.1.6.3(name, purpose, identifier, contact information, license details)

Page 18 of 111

Leasing agreements, including a current list of leases (name, purpose, terms, 8.1.6.4dates, contact information)

Service contracts, including a current list of contracts (name, purpose, terms, 8.1.6.5dates, contact information)

Customer information (for example, current and historical data records, 8.1.6.6Transaction processing histories, images, scanned and hard copy documents, open call center cases, applications, forms, correspondence)

Customer notification outreach 8.1.6.7

Call routing 8.1.6.8

Financial ledgers and other financial information 8.1.6.9

LPT System configuration histories 8.1.6.10

Archived data 8.1.6.11

Correspondence templates (editable electronic and printed copies) 8.1.6.12

Invoice/ violation notice templates (editable electronic and printed copies) 8.1.6.13

Current Policies and Procedures documentation 8.1.6.14

Other information or knowledge necessary for succession or as otherwise 8.1.6.15reasonably requested by OTA

8.1.7 The LPT Processor shall update the approved Succession Plan to account for any subsequent changes in policy or operations within 30 days of the change. The updated Succession Plan shall be submitted to OTA for review and approval.

Succession Procedures 8.2

8.2.1 In the event that Notice of Succession is given to the LPT Processor by OTA, the LPT Processor shall designate a succession manager to be a single point of contact for all succession-related issues. The succession manager shall convene regular meetings with relevant staff and with OTA or its designated representatives, at which succession-related issues can be tracked, discussed, and resolved.

8.2.2 Upon Notice of Succession, the LPT Processor shall immediately coordinate formal reviews of all succession activities as detailed in the Succession Plan.

8.2.3 Upon Notice of Succession, the LPT Processor shall develop, submit to OTA for review, finalize, and subsequently adhere to a succession transition schedule that accommodates the needs of the Successor and/or OTA, relative to smoothly transitioning to a new LPT Processor and/or OTA.

Page 19 of 111

8.2.4 Upon Notice of Succession, the LPT Processor shall provide staff time to work with OTA and/or the Successor to establish database extract procedures acceptable to the OTA and/or the Successor, for the purpose of migrating the LPT System data.

8.2.5 Upon Notice of Succession, the LPT Processor shall provide staff time to work with OTA and/or the Successor to establish mapping conventions acceptable to the OTA and/or the Successor, for the purpose of migrating data to the new LPT Processor.

8.2.6 In the event of a succession, the LPT Processor shall make its existing management staff available for in-person interviews with OTA and/or the Successor staff.

8.2.7 The LPT Processor shall provide in-person training of Successor and/or OTA staff with experienced LPT Processor staff on an “as needed” basis upon request of OTA for a period from Notice of Succession until the end of the Term.

8.2.8 In the event of a succession, the LPT Processor shall ensure the accustomed quantity and quality of staff, supervisors and management are maintained throughout the entire period during which LPT operations is being transitioned to the Successor or OTA.

Page 20 of 111

II. Design, Development and Testing

This section outlines the system design, development and testing requirements for implementing the LPT System and processes. This phase includes Software design and Software development, as well as preparation of all materials, facilities and hardware necessary for the LPT operation. Design, development and testing shall require OTA participation and approvals throughout the process, beginning with the creation of a System Design and Development Plan (SDDP) and a review of the Requirements Traceability Matrix (RTM) in Appendix A. These documents shall form the basis of the initial LPT System design embodied in the System Design Document (SDD). During workshop sessions and OTA reviews, the LPT Processor shall refine the design resulting in an SDD that shall lead to LPT System development. This phase also includes creation and detailed reviews of Policies and Procedures and series of tests of the entire LPT System.

9 System Development

System Design and Development Plan (SDDP) 9.1

9.1.1 The LPT Processor shall provide for OTA’s review and approval a SDDP that defines the LPT Processor’s approach to design and development of the LPT System.

9.1.2 The SDDP shall include specific details of system development, including definition, design, programming, submittal and acceptance of software design deliverables, documentation, and software quality assurance.

9.1.3 The SDDP shall include the software life-cycle methodology that will be utilized as well as the technical approach, problem reporting and tracking process, software configuration and change management, and regression testing and revision control.

9.1.4 The SDDP shall include plans for design, development, testing and implementation of interfaces between the LPT System and external entities, as described in Appendix E.

9.1.5 The SDDP shall be used for future LPT System modification beyond minor bug fixes. At a minimum, for post-acceptance changes, the process shall include a business case and written acceptance of this document by OTA.

9.1.6 The SDDP shall provide a description of the structure of the software development team that will be assigned to the Project and how personnel will be assigned to the various system development disciplines, including software development, system engineers, test engineers, software test personnel, configuration management staff, documentation specialists, project management staff and software maintenance personnel.

Page 21 of 111

Requirements Review Workshops 9.2

9.2.1 The LPT Processor shall facilitate workshops with OTA and other parties designated by OTA to refine the requirements, covering at least customer communications, finance, accounting, reporting, website, and operations.

9.2.2 During these workshops, the LPT Processor shall clarify system requirements and Business Rules to ensure a full understanding of the intent of the system functions and Business Rules. The LPT Processor shall discuss how it shall meet requirements through operational procedures, the LPT Processor’s existing system functionality, system configuration or enhancements to its LPT System.

9.2.3 The LPT Processor shall participate in all meetings with OTA and other parties designated by OTA to determine the requirements for the various interfaces, as directed by OTA.

Requirements Traceability Matrix (RTM) 9.3

9.3.1 The LPT Processor shall update the Requirements Traceability Matrix in Appendix A with the results of the workshops and provide it to OTA for approval.

9.3.2 The LPT Processor shall continuously maintain and update the RTM throughout the life of the Project and shall include only OTA-directed requirements or OTA-approved changes that affect the design or functionality of Project hardware or software thereto.

9.3.3 The RTM shall show the origin of requirements, any changes to requirements, and the source of approval for those changes.

9.3.4 The RTM shall be used to verify compliance throughout the system design and development phase, testing and deployment, and into the Operations Phase.

9.3.5 The LPT Processor shall ensure the LPT System and all supporting activities and deliverables comply with the RTM throughout the entire life cycle of the Project.

9.3.6 The LPT Processor shall deliver an OTA-approved RTM in accordance with the approved Project Schedule.

10 Design

General Design Requirements 10.1

10.1.1 The LPT Processor shall produce a Preliminary Design Document (PDD) and a System Design Document (SDD) covering the applicable RTM items and the approved Business Rules.

Page 22 of 111

Preliminary Design Document and Review 10.2

10.2.1 The Preliminary Design Document (PDD) shall contain detailed information on LPT system design and technical approach and shall include, but not be limited to, the following:

General system design 10.2.1.1

RTM 10.2.1.2

System software specifications and design 10.2.1.3

System hardware specifications and design with cut sheets 10.2.1.4

System and software of the phone system 10.2.1.5

Physical and logical network overview 10.2.1.6

10.2.2 The LPT Processor shall provide system and subsystem block diagrams and data flow diagrams, and demonstrate compliance with system requirements.

10.2.3 The LPT Processor shall submit hardware concept drawings during this review.

10.2.4 The LPT Processor shall submit the PDD three weeks in advance of the scheduled PDR workshop. The PDD will be reviewed by OTA and comments provided to the LPT Processor.

10.2.5 The PDR workshop will be held to review the design documentation, discuss OTA comments and provide an in-depth review of the system design and the design documentation.

10.2.6 The PDR workshop shall take place at OTA offices. The LPT Processor shall provide minutes/action items from the PDR and submit revised versions of the documentation for OTA review and approval. This process will be repeated until OTA determines that the PDD is acceptable.

System Design Document (SDD) and Review 10.3

10.3.1 The SDD shall be an extension of the approved PDD documents and shall include detail such as block diagrams, hardware and software design, user interface and screen layouts, report formats, operational procedures, other pertinent design documentation including a list of equipment for each function along with a description of its role.

10.3.2 The SDD shall include, but not be limited to, the following:

Scope of Project 10.3.2.1

RTM 10.3.2.2

Page 23 of 111

Specification sheets for all equipment 10.3.2.3

Full software manual set for all Commercial off the Shelf (COTS) software 10.3.2.4as requested by OTA

System sizing and design details 10.3.2.5

Description of all third party software, including Operating Systems 10.3.2.6

System, subsystem and module level descriptions 10.3.2.7

Description of interactions between modules 10.3.2.8

Requirements for all peripheral device interfaces 10.3.2.9

Examples (mockups) of all reports 10.3.2.10

Description of system diagnostics, status monitoring and error handling 10.3.2.11

Description of redundancy and failover processes 10.3.2.12

End to end transaction diagram 10.3.2.13

Interface Control Documents (ICDs) for all external entities 10.3.2.14

File and transaction message formats 10.3.2.15

Design for user interfaces including graphical representation (screen shots 10.3.2.16or mockups) of all menus and screens

Database design and ERD/Data Dictionary 10.3.2.17

Basic Data communications diagram 10.3.2.18

Communications network logical design 10.3.2.19

Communications network physical design 10.3.2.20

10.3.3 The LPT Processor will submit a SDD for design approval that describes the design specifications of all hardware, software and communications to be provided by the LPT Processor to meet the requirements of the Project.

10.3.4 The LPT Processor shall describe all hardware specifications, including appropriate diagrams and facility layouts, in the hardware design.

10.3.5 The LPT Processor shall illustrate the software design and architecture and include modules and/or process levels and procedures. The software design details shall include the code used and how it interacts with the underlying Operating System.

Page 24 of 111

10.3.6 The SDD will form the basis for the Detail Design Review (DDR) and will be submitted for review, comment and discussion, after which the design reviews will take place.

10.3.7 The DDR provides the final review of the SDD, as implemented in accordance with the approved PDR approach.

10.3.8 The SDD must be received from the LPT Processor no later than three weeks in advance of the scheduled DDR meeting to allow OTA to review the documents in detail prior to the meeting.

10.3.9 Upon completion of the design reviews, the SDD shall be revised and submitted to OTA for final review and approval.

10.3.10 Upon OTA’s approval of the SDD, the LPT Processor shall update the Project Schedule, if necessary, and the RTM to reflect any changes in requirements approved during the design process.

10.3.11 The LPT Processor shall provide minutes/action items from the DDR and submit revised versions of the documentation for OTA review and approval. This process will be repeated until OTA determines that the SDD is acceptable.

10.3.12 Within 30 days after successful completion of the System Acceptance Test, the LPT Processor shall submit the Final SDD, including all changes made during the software development, installation and testing phases.

10.3.13 The LPT Processor shall provide all hardcopy submittals in three-ring binders, accompanied by electronic (soft) copies.

10.3.14 The LPT Processor shall update and submit to the designate person at OTA, the Final SDD with any changes implemented during ongoing operations within 10 business days of the change.

11 Testing Requirements

General Testing Requirements 11.1

The requirements described in this Section detail the test phases, facility, and support services necessary to test the LPT System.

11.1.1 The LPT Processor shall conduct testing of the system to validate the LPT System integrity, reliability, functionality, accuracy and compliance to the requirements of this RFP and demonstrate that the LPT System meets all of the approved requirements in the RTM.

Page 25 of 111

11.1.2 OTA and its representatives shall have the option to witness or take part in, any or all testing, and the LPT Processor shall work with OTA to schedule tests so that OTA staff, representatives and partners may observe and/or participate in all formal testing.

11.1.3 During the development of the system software, the LPT Processor’s test personnel shall conduct a comprehensive program of internal testing and walk-through sessions with OTA to ensure that the LPT System meets the functional specifications set forth in this RFP and that defects are detected and resolved or identified prior to formal demonstration testing witnessed by OTA.

11.1.4 The LPT Processor shall be responsible for all development and test personnel, equipment, facilities and expenses associated with all system testing.

11.1.5 The LPT Processor shall submit test plans, with test scripts, to OTA for review, comment and approval, at least 15 business days in advance of each test.

11.1.6 The LPT Processor shall incorporate comments and revisions received from OTA and update the Project Schedule, if necessary.

11.1.7 The LPT Processor shall obtain OTA approval of test plans and scripts prior to testing.

11.1.8 The LPT Processor shall accommodate ad hoc testing by OTA during formal testing.

11.1.9 The LPT Processor shall conduct all tests in accordance with the project schedule and the approved test plans and procedures.

11.1.10 Within 10 calendar days of the completion of each test, the LPT Processor shall deliver a test results report to OTA which shall include a listing of all defects (punch list) identified together with the severity level of each (severity levels will be determined in the Master Test Plan); a plan for resolving those defects; and a recommendation for retests (if appropriate).

11.1.11 The LPT Processor shall provide to OTA a report of all test results, notes, and observations.

11.1.12 The LPT Processor shall work together with OTA to indicate a priority level for each punch list item.

11.1.13 The LPT Processor shall correct and retest all punch list items including necessary regression.

11.1.14 The LPT Processor and OTA shall agree on a schedule for correcting and retesting punch list items.

11.1.15 When OTA deems that all punch list items have been resolved, the LPT Processor shall receive final approval of that test.

Page 26 of 111

Master Test Plan (MTP) 11.2

11.2.1 The LPT Processor shall provide a Master Test Plan describing all tests to be performed from NTP through and including System & Operational Acceptance.

11.2.2 The final set of tests to be conducted shall be finalized during the design phase; however, at a minimum, the LPT Processor shall include the following tests in the Master Test Plan:

Page 27 of 111

Table 1: Testing Summary

11.2.3 The MTP shall provide a description of each test, the standards for developing

individual test plans and the procedures for the formal testing. These standards shall address test procedure format, severity levels and acceptance criteria for each formal test phase. In addition, the MTP shall describe the entry criteria that must be met before each formal test can be started and the exit criteria that must be met before each test can be considered complete.

11.2.4 The MTP shall address testing approaches and schedule, performance criteria, data collection and sampling methods, testing conditions, testing locations, reporting of results, and procedures for tracking and retesting/regression testing for failed tests.

11.2.5 The MTP shall be submitted to OTA for review and approval according to the approved Project Schedule.

Test Entry Criteria Exit Criteria Description Documentation Factory Acceptance Test (FAT)

Approval of System Design Document, RTM, Master Test Plan, and all associated documentation.

Approval from OTA of successful completion of FAT.

Demonstrate the approved requirements and design of the LPT System.

FAT plan Test scripts Test results report Punch List (if any)

Installation and Interface Test (IIT)

Approval of IIT Plan; Policies and Procedures Manual and user manuals; Successful completion of exit criteria from FAT.

Approval from OTA of successful completion of IIT.

Demonstrate the proper function of all network communications and other physical systems and all external interfaces.

IIT plan Policies and Procedures User manuals Test scripts Test results report Punch List (if any)

Disaster Recovery Test (DRT)

Approval of Disaster Recovery Plan and successful completion of IIT.

Approval from OTA of successful completion of DRT.

Demonstrate the continued operation of the LPT System in the event of a disaster.

DRT plan Test scripts Test results report Punch List (if any)

Production Readiness Test (PRT)

Approval of Production Readiness Test Plan and successful completion IIT.

Approval from OTA of successful completion of PRT and OTA approval of SOAT Plan

Demonstrate the complete functionality and processes at the CSC. Successful completion of the PRT signals the LPT System is ready for Go-Live.

PRT plan Test scripts Test results report Punch List (if any) SOAT plan

System & Operational Acceptance Test (SOAT)

Approval of SOAT Plan (required prior to the end of PRT) Successful completion of exit criteria from PRT.

Completion and approval from OTA of SOAT

Demonstrate compliance with all requirements of SOW and all Performance Standards.

SOAT Plan Test results report

Page 28 of 111

General Test Plan Requirements 11.3

11.3.1 The LPT Processor shall provide for OTA’s review and approval (prior to test commencement) an individual test plan for each test listed in Table 1.

11.3.2 Each test plan shall include a description, scope, approach, required resources, schedule, including test items, all dependencies (including reliance on and readiness of third parties), test platform (including required equipment and location), features to be tested, test scripts and their expected results, entry and exit criteria including pass/fail criteria, a placeholder to record any defects noted during the test and a description of the ranking that will be used for classifying and recording any defects noted (e.g. critical, major, minor), definitions of a successful test, a place holder to record actual results and any risks requiring contingency planning.

11.3.3 The LPT Processor shall provide all test and support personnel, test equipment and test sites in accordance with the approved Master Test Plan. OTA will review and approve formal test plans and schedules proposed by the LPT Processor and will witness and determine the acceptability of the test results.

11.3.4 Test plans shall document workflows and business processes established during the design phase.

11.3.5 Test plans shall clearly list requirements that the LPT Processor will not test at each respective stage and the reason for their exclusion. These excluded requirements shall be subject to OTA review and approval.

11.3.6 Test plans shall describe how data to be tested will be compiled, such as through use of data simulation software or other mutually agreed upon data sets to create necessary Transaction and payment data.

11.3.7 The LPT Processor shall update each version of the test plans to incorporate or respond to OTA comments on the previous version.

11.3.8 The Factory Acceptance Test plan shall be submitted for OTA approval no sooner than 15 business days after approval of the SDD.

Factory Acceptance Test (FAT) 11.4

11.4.1 LPT Processor shall conduct the Factory Acceptance Test at the end of the development phase in accordance with the approved Project Schedule.

11.4.2 The FAT shall take place at the LPT Processor’s development facility or other equivalent site in the continental United States.

Page 29 of 111

11.4.3 The FAT shall be a test of the LPT System, using the same communications equipment, software, hardware, user interfaces and configurations as the LPT Processor will use in production.

11.4.4 The FAT shall follow a set of transactions and payments through various use cases that demonstrate the workflow through various sub-systems including LPT processing, image review, Interactive Voice Response (IVR) system, website, customer statements/invoices, and reports, etc.

11.4.5 The LPT Processor shall coordinate with OTA on how to obtain test Transaction and image file data.

11.4.6 The FAT shall utilize compiled Transaction and payment data to perform tests including, but not limited to, a full range of required reports, financial data flow and Transaction and payment reconciliation.

11.4.7 The LPT Processor shall obtain OTA approval of FAT results prior to Installation and Interface Testing.

Installation and Interface Test 11.5

11.5.1 The LPT Processor shall conduct the Installation and Interface Test after the LPT System has been installed in the designated primary hosting site location.

11.5.2 The Installation and Interface Test shall thoroughly test all of the network communications and other physical systems, according to a plan to be approved by OTA.

11.5.3 To the extent possible, the LPT Processor shall acquire test files from external interface sources to allow for the widest possible tests of LPT System functionality.

11.5.4 The LPT Processor shall cooperate with all testing required by third parties with external interfaces as directed by OTA.

11.5.5 The LPT Processor shall demonstrate the interface with the OTA Host to show that it can receive and process Transaction and image files, send results files back through the interface in the agreed-upon format, and show proper system logs of the send/receive cycle.

11.5.6 At a minimum, the LPT Processor shall include the following interfaces in the Installation and Interface Test:

Host/PIKEPASS 11.5.6.1

Credit/debit card processors 11.5.6.2

Banks 11.5.6.3

DMV/Third parties 11.5.6.4

Page 30 of 111

Mailhouse 11.5.6.5

Collection Agency 11.5.6.6

11.5.7 The LPT Processor shall obtain OTA approval of the Installation and Interface Test results prior to Disaster Recovery testing and the Production Readiness Test.

Disaster Recovery Test 11.6

11.6.1 During the Disaster Recovery Test, the LPT Processor shall exercise the Disaster Recovery/Business Continuity Plan to the fullest extent possible, simulating various LPT System failures and challenges for LPT Processor staff.

11.6.2 The LPT Processor shall obtain OTA approval of Disaster Recovery Test results prior to Go-Live.

11.6.3 The LPT Processor shall conduct the Disaster Recovery Test during Production Readiness Testing.

11.6.4 The LPT Processor shall conduct Disaster Recovery Testing at least annually after Go-Live.

Production Readiness Test 11.7

The Production Readiness Test (PRT) is performed in accordance with the PRT Plan approved by OTA, pending completion of construction. During the PRT, the full systems and operations of LPT System will be operating. Note that during PRT, no transactions will post to production, but instead shall post to a test platform designed to replicate the end-state production for ease of analysis and evaluation. During the PRT, the TransCore Infinity and OTA CE systems will be in operation and will process all PIKEPASS customer transactions from the new AET toll points, and will forward all image-based transactions to the LPT Processor. The objective of the PRT is to exercise all functionality and performance of the LPT System, operations, and maintenance, including but not limited to system logic, system administration, back office functionality, data communications, file transfers, Image Review process, reconciliations, interactions with the Host, Subcontractors and other third parties.

11.7.1 The PRT shall continue until the results are approved by OTA. The goal of a successful PRT is to prove the LPT System and operations are ready for production and the decision to ‘Go-Live.’

11.7.2 Upon completion of construction of each ramp, the LPT Processor shall begin to receive and process transaction and image data from the Host to the LPT System for use in exercising the functionality and processes at the CSC.

11.7.3 The LPT Processor shall perform the Production Readiness Test using actual Host data from transactions created at the Elm-Peoria toll points until Go-Live.

Page 31 of 111

11.7.4 The LPT Processor shall provide documentation of the agreed-to system configuration as part of the Production Readiness Test Plan.

11.7.5 This Production Readiness Test shall include but not be limited to:

Creating new accounts, issuing invoices, violations, payment processing, 11.7.5.1handling disputes and managing accounts through the website, and IVR system

Invoice escalation including violations and collections 11.7.5.2

Making adjustments in the LPT System to emulate all account and financial 11.7.5.3functions, including transfer of responsibility, chargebacks, refunds, and NSF checks

Interfacing with OTA’s finance department and systems 11.7.5.4

Providing special ad hoc queries, running daily and weekly reports, and 11.7.5.5conducting research on possible issues

Setting up test credit/debit cards and other mechanisms to simulate payments 11.7.5.6

Testing of LPT accounts and maintenance functions 11.7.5.7

Call routing between the LPT Processor and PIKEPASS 11.7.5.8

11.7.6 The LPT Processor shall perform license plate lookup queries during the Production Readiness Test.

11.7.7 The LPT Processor shall coordinate with DMVs and any third party DMV services to test the ROV lookup and license/registration hold interface.

11.7.8 The LPT Processor shall provide all necessary training and support in the use of the PIKEPASS CSC resources and LPT System to all users prior to conducting the Production Readiness Test.

11.7.9 The LPT Processor shall provide remote access for OTA and its representatives to access the LPT System during the Production Readiness Test.

11.7.10 The LPT Processor shall track and document all anomalies, failures, and other issues noted by test participants and observers during this period.

11.7.11 The LPT Processor shall prepare and deliver a test report with all issues prioritized and corrective actions assigned on a weekly basis.

11.7.12 The LPT Processor shall work with OTA to determine and agree upon required retesting.

Page 32 of 111

11.7.13 The LPT Processor shall continue testing data and recording, prioritizing, and working to correct issues identified until OTA approves a final set of Production Readiness Test results.

System & Operational Acceptance Test 11.8

11.8.1 The System & Operational Acceptance Test shall begin immediately upon Go-Live or as soon as all criteria for entry to this test have been met.

11.8.2 The System & Operational Acceptance Test shall include but not be limited to:

Ensuring the accuracy, consistency and completeness of data recorded in the 11.8.2.1database and reflected in reports

Performance monitoring and ensuring that all requirements and Performance 11.8.2.2Standards are met or exceeded

Following Policies and Procedures, resulting in an efficiently functioning 11.8.2.3CSC that meets all requirements

11.8.3 The LPT Processor shall perform a detailed review of all financial reports, which shall determine that all transactions are accurately summarized, fully accounted for, and supported by detailed Transaction reports.

11.8.4 The LPT Processor shall create a punch list of defects and a report on Performance Standards early in the System & Operational Acceptance Test period to allow early fixes and testing without revenue impacts to the Project. Approval of the System & Operational Acceptance Test shall occur when the LPT Processor demonstrates that it meets all requirements in the SOAT Plan and achieves compliance with all required Performance Standards over 3 consecutive calendar months of CSC Operations.

12 Go-Live

General Go-Live Requirements 12.1

12.1.1 The Go-Live period shall occur over a maximum of three days.

12.1.2 The LPT Processor shall have completed and obtained OTA approval for all testing except System & Operational Acceptance.

12.1.3 The LPT Processor shall provide a detailed Go-Live Plan covering the three-day Go-Live period.

12.1.4 The Go-Live plan shall include an hour-by-hour schedule, a checklist of tasks and tests occurring during Go-Live, the go/no-go decision point, and any other information necessary to ensure a smooth Go-Live.

Page 33 of 111

12.1.5 The LPT Processor shall evaluate all aspects of its planned operations and ensure that all mechanisms are in place to manage those operations in accordance with all requirements prior to Go-Live.

12.1.6 The LPT Processor shall report on its evaluation to OTA, seek OTA’s approval for implementing any resulting recommendations, and document any such measures implemented.

III. License Plate Tolling Operational Requirements

The LPT Processor shall be responsible for the management and on-going operation of the OTA License Plate Tolling operations and all related activities. These activities include, but are not limited to, image review, invoice generation and issuance, account creation and management, payment processing, customer communications, interfacing with external entities, customer interaction; reconciliation and report generation. Except as specifically stated in this Scope of Services, the LPT Processor shall supply all LPT System and Main Processing Center facilities, enclosures, hardware, software, utilities, and staff necessary to meet the requirements of this Scope of Services.

13 Technical Requirements

System Requirements 13.1

LPT System Data Center Requirements 13.1

13.1.1 The LPT Processor shall provide both a Primary and a Disaster Recovery (DR) data center, with a minimum Tier 3 rating, to house the required infrastructure to process designated OTA LPT transactions and images. A Tier 3 data center is composed of multiple active power and cooling distribution paths, but only one path active, has redundant components, and is concurrently maintainable, providing 99.982% availability.

13.1.2 In both the Primary and DR data centers, the LPT Processor shall maintain and monitor the HVAC(s) system such that it provides the proper environmental conditions that are required for the LPT System.

13.1.3 The LPT Processor shall ensure the LPT System data center components are protected from power outages by the use of generators.

13.1.4 The LPT Processor shall ensure LPT System components are protected by a Power Distribution Unit (PDU) and an Uninterruptible Power Supply (UPS) capable of surge suppression and powering the LPT System during utility to generator transfers.

13.1.5 The LPT Processor shall monitor all PDUs and UPSs for health and loading.

Page 34 of 111

13.1.6 The LPT Processor shall design, procure and configure a physical and logical Local Area Network (LAN) for the LPT System at the Primary and DR data centers using commercially available hardware.

13.1.7 The LAN topology shall be designed to eliminate single points of failure at network layers 1, 2, and 3. The design and equipment shall be subject to OTA review and approval.

13.1.8 The OTA LPT System shall exclusively use the LAN. No other systems housed in the LPT Processor’s data centers shall use the LAN provided to OTA.

13.1.9 In order to establish communication paths between the Host, LPT Account holders, third party interfaces, and data center to data center a Wide Area Network (WAN) connection shall be provided by the LPT Processor at both the Primary and Disaster Recovery data centers.

13.1.10 It is the LPT Processor’s responsibility to provide and configure all required equipment and cabling to accommodate the WAN link.

13.1.11 The LPT Processor shall coordinate with third party Internet Service Providers (ISP) to install the WAN link within each LPT System data center. The up front and recurring costs of the WAN link shall be the responsibility of the LPT Processor.

13.1.12 The LPT Processor’s WAN topology, bandwidth, and equipment shall be subject to OTA review and approval.

13.1.13 The LPT Processor shall ensure that no data is lost in the event of a data transmission failure.

13.1.14 The LPT System data center components shall be housed in their own secured cabinet/rack. Only authorized and OTA approved personnel shall have access to the LPT System Facility rack.

LPT System Requirements 13.2

13.2.1 The LPT Processor shall furnish an active-standby LPT System between its Primary and DR Data Centers. The LPT System shall include all cabinets, enclosures, servers, storage systems, Keyboard, Video, and Monitor (KVM)s, cabling, and any ancillary equipment, as may be necessary to provide a complete and acceptable LPT System and shall be designed, sized and maintained to meet or exceed all operational and functional requirements and all Performance Standards in this RFP throughout the Term.

13.2.2 The LPT System shall be scalable to meet increased volumes.

13.2.3 The LPT Processor shall provide an isolated LPT System, meaning it will not share physical or logical system, network, or infrastructure components with other co-

Page 35 of 111

located clients. Two exceptions for sharing physical components are the data building and the data center utility power.

13.2.4 The LPT Processor shall provide hosts that contain adequate memory and processing capacity to meet all requirements.

13.2.5 The LPT System shall include hot swappable components and sub-systems wherever available.

LPT System Operating System and Software 13.3

13.3.1 The operating system for the LPT System(s)/server(s) shall consist of a Commercial Off the Shelf (COTS) multi-user, multitasking operating system.

13.3.2 The LPT Processor is responsible for obtaining all licenses as required and all necessary licenses will be obtained for all COTS operating system software used by the LPT System.

13.3.3 The LPT Processor will retain authorized copies (backups) for all software media to use for periodic system maintenance, upgrades, or restorations, as required.

13.3.4 The proposed operating system shall have warranty and COTS maintenance support services for the Term of the Contract.

13.3.5 If Microsoft Windows is selected, the LPT Processor shall utilize Microsoft Windows 7 or greater for desktops and Windows Server 2012 R2 or greater for servers.

13.3.6 The operating system shall be a proven system and version release with a large installed base, used widely throughout the United States for enterprise-class operations and shall be compatible with relevant database and web-based development and operational tools, and shall not be a “Beta” or first release version.

13.3.7 The LPT Processor shall maintain the Operating System with necessary updates and security patches.

LPT System Dashboard 13.4

13.4.1 The LPT System shall provide a dashboard screen that allows authorized users to monitor the LPT System with drilldown capabilities. This shall include an overview of LPT operations including transaction volume by facility, call center activity, image review, ROV lookups, invoice/violation issuance and escalation, and number of accounts. Specific examples of detail include:

Call Center 13.4.1.1

• Total incoming calls

• Number of calls requesting a CSR

Page 36 of 111

• Number of calls answered by a CSR • Average wait time for CSR calls

• Average call handling time • Maximum wait time for CSR calls

• Number & Percentage of CSR calls that exceed a specified wait time • Abandoned call rate

Image Review 13.4.1.2

• Oldest transaction date currently being reviewed

• Percentage of images rejected • Top 3 image reject reasons

• Number of image in queue 13.4.2 The dashboard shall allow drilldown capabilities for each of these areas so that users

can view activity on an hourly, daily, weekly, monthly and annual basis. It shall also include comparisons to prior activity.

13.4.3 The dashboard shall provide a visual and graphical representation of the Transaction workflow and shall display data in real-time as well as historical roll-up.

13.4.4 The LPT Processor shall monitor the dashboard and also allow OTA to view the dashboard 24/7/365 on a real time basis. All information that is related to different locations shall be tracked individually as well as in total.

13.4.5 End users shall have the ability to customize their own dashboards by changing column sort criteria, changing the order that columns of data are displayed and hiding columns.

13.4.6 The LPT System shall allow users to establish configurable thresholds for monitoring LPT System and operational performance.

13.4.7 The LPT System shall generate alerts when deviations from established thresholds occur.

Database Requirements 13.5

13.5.1 The LPT System database shall incorporate redundancy in order to minimize LPT System downtime.

13.5.2 The LPT Processor shall design and configure the LPT System database to minimize the possibility of data loss.

13.5.3 The LPT Processor shall design and configure the LPT System database to support future hardware and software upgrades.

Page 37 of 111

13.5.4 The LPT Processor shall design the LPT System database to be compatible with the operating system and application software.

13.5.5 The LPT Processor shall design the LPT System database to support redundant central processing system architectures.

13.5.6 The LPT Processor shall provide database software with warranty and maintenance support services for the term of the contract.

13.5.7 The LPT Processor shall keep the LPT System database software current—that is, within one major release of the database manufacturer's current general production version.

13.5.8 If Microsoft SQL Server is selected, the LPT Processor shall utilize Microsoft SQL Server 2014 or greater for database software.

13.5.9 The LPT Processor shall provide database monitoring tools such that all aspects of the database are monitored, including but not limited to software capable of alerting appropriate staff to the presence of alarm conditions, capable of giving authorized users real time overviews, details, histories, and maintenance tools suitable for investigating and making adjustments to LPT System database performance, session-level activity, scheduled jobs, alert notification and configuration parameters.

13.5.10 The LPT Processor shall provide and maintain a reporting database or a data warehouse that replicates all the data from the LPT System database, in near real time, to be used for all user-generated reports, including those described in the reports section of this Scope of Services.

13.5.11 The LPT Processor shall configure the reporting database or data warehouse so as to optimize report generation including appropriate indexes and views to allow ad-hoc user generated queries.

13.5.12 The LPT System database shall store certain fields in encrypted form (for example credit/debit card numbers), as determined with OTA during system design. It is the preference of OTA not to maintain social security and/or driver’s license numbers within the LPT System; however OTA understands that some information may be automatically returned by certain DMV sources. In the event that personal information is obtained, the LPT Processor shall ensure this data is fully protected in compliance with prudent personally identifiable information (PII) provisions.

13.5.13 The LPT System database design shall utilize mechanisms designed to protect data integrity including but not limited to: normalized data, foreign key relationships, field-level value constraints, application user roles, data validation triggers, and use of materialized views and prevention of direct base table access by use of stored procedures and views.

13.5.14 The LPT System database design shall incorporate field-level validation whenever possible to limit the possibility of data entry or manual update errors; including but not

Page 38 of 111

limited to: foreign keys, dollar amount range checks, and telephone number and zip code masks.

13.5.15 For post-System & Operational Acceptance LPT System changes, prior to a change being implemented on a production database, a written test and acceptance plan shall be developed, executed and the results accepted in writing by OTA.

LPT System End User Requirements 13.1

13.1.1 The LPT System shall employ a 100% browser based, graphical user interface (GUI), or a comparable user interface of equal or greater quality and capability that does not require specialized software. A browser is defined as a software program that allows the user to open the GUI in a form that is suitable for display.

13.1.2 The LPT System shall be configurable and shall have appropriate interactive GUIs to allow authorized staff to manage the various configuration parameters required for proper LPT System operation.

14 Security

General Security Requirement 14.1

14.1.1 The LPT Processor shall ensure the LPT System is secured against unauthorized access, data loss, and data integrity loss.

14.1.2 The LPT Processor shall, at a minimum, adhere to the OTA Information Security Policy (see Appendix H) and Physical Security Policy (see Appendix I).

Access Security 14.2

14.2.1 Access to the operating system, database, Virtual Private Network (VPN), and all other applications, shall be controlled by system administrators, on a per-user basis.

14.2.2 The LPT System shall ensure that all user access to any part of the LPT System, except for the customer-facing website, shall be managed from a single directory of authorized users. The LPT System must validate user accounts against a directory service. For example: if the agency disables or locks a user network account via active directory, the LPT application can test for an active, enabled user account. This is so credentials can be maintained in the LPT System but also checked for a valid directory account.

14.2.3 The authorized user directory shall be the authorization provider for, at a minimum, operating system access, database level access, remote access, and access to the user-level application.

14.2.4 All updates to the authorized user directory shall be securely logged.

Page 39 of 111

14.2.5 System administrator logs and other logs shall be monitored for exceptions and/or improper activity and this log monitoring shall be documented and automated to the extent possible (e.g., use of system log monitoring tools).

14.2.6 Passwords shall be required for access to any part of the LPT System.

14.2.7 All accessible subsystems, including the customer-facing website, shall have the ability to limit valid passwords by length and use of special characters, and to restrict repeated use of the same password by a single user.

14.2.8 All accessible subsystems, including the customer-facing website, shall have the ability to require passwords to be changed periodically.

14.2.9 LPT System functionality shall be secured by passwords and security roles.

14.2.10 The LPT System security role set shall include a role enabling its users to assign or remove security role(s) of other users.

14.2.11 The LPT System security role set shall include a role enabling its users to reconfigure the LPT System rights, which are enabled by other security roles.

14.2.12 The LPT Processor, in conjunction with OTA, shall develop LPT System rights and security roles during the design process.

14.2.13 The LPT Processor shall grant user access based on the OTA-approved Policies and Procedures.

14.2.14 The LPT System shall allow for role-based user access configuration.

14.2.15 The LPT System shall require each user to have unique logon credentials.

14.2.16 The LPT System shall allow user access to be controlled by a system administrator.

14.2.17 The LPT System shall automatically log database records for all user access and all user activity that results in data updates or access to customer data.

14.2.18 The LPT System shall provide functionality for searching the user access logs using commonly available file system or database utilities.

14.2.19 The LPT System shall provide controls to lock out users after a configurable number of unsuccessful system login attempts.

14.2.20 The LPT System shall provide tools that will detect and report any intrusions and/or attempted intrusions.

Data Security 14.3

14.3.1 The LPT Processor shall be responsible for all aspects of protecting LPT System data.

Page 40 of 111

14.3.2 The LPT Processor shall employ methods to ensure reliable data communications, file transfer and integrity of the database and tools that detect interruption of these.

14.3.3 The LPT Processor shall provide and implement a systematic method for archiving and purging data and ensure that the entire LPT System software and data is backed-up and stored at an off-site location.

14.3.4 The LPT Processor shall ensure that application activity is logged in a common log file format with searchable, and human-readable log files.

14.3.5 The LPT Processor shall configure all operating systems and databases such that all non-essential users, features, and services are either locked or removed.

14.3.6 The LPT Processor shall strengthen all operating system and database passwords, including passwords for LPT System and application users, in accordance with industry best practices.

14.3.7 The LPT Processor shall ensure that system administrator level access is limited, and that any administrator level access is logged.

14.3.8 The LPT Processor shall ensure that operating systems and databases are up to date with the latest security patches.

14.3.9 The LPT Processor shall employ an auditing strategy for the LPT System that maximizes the possibility of detecting unauthorized activity. This shall include an automated event notification and logging process.

14.3.10 The LPT System shall allow the LPT Processor to create user roles and assign/restrict account access and management rights according to training and Policies and Procedures that are documented by the LPT Processor and approved by OTA.

14.3.11 The LPT System shall support configuration of user roles that limits access to sensitive data in compliance with PCI requirements.

14.3.12 The LPT Processor shall ensure that all Microsoft Windows servers and workstations used on the Project have up-to-date virus protection and security management software that are monitored and managed via centrally managed back end software and/or MOMS.

Payment Card Industry Data Security Standard (PCI DSS) 14.4

14.4.1 All systems provided and data maintained by the LPT Processor shall be continually in full compliance with the most current PCI DSS at all times.

14.4.2 The LPT System shall provide for OTA’s classification as a Level 1 merchant as defined in PCI DSS.

Page 41 of 111

14.4.3 The LPT Processor shall retain a highly qualified and credentialed 3rd party firm to annually certify that all systems provided by the LPT Processor and all processes operated by the LPT Processor meet the PCI DSS requirements. OTA shall approve the PCI DSS compliance subcontractor, and the cost of annual exams shall be borne by the LPT Processor.

14.4.4 The LPT Processor shall provide to OTA prior to Go-Live and annually thereafter, the compliance subcontractor’s report detailing the compliance, including identifying the version of PCI DSS compliance with which each system or process complies.

14.4.5 The LPT Processor shall resolve compliance exceptions in accordance with the Performance Standards. The LPT Processor shall bear the cost of resolving all compliance exceptions including costs related to changes to PCI DSS standards.

15 System Administration & Maintenance

General System Administration & Maintenance Requirements 15.1

15.1.1 The LPT Processor shall be responsible for the resolution of all LPT System issues, Software bugs, required upgrades, users, passwords and LPT System security.

15.1.2 The LPT Processor shall develop a System Administration Manual that details the LPT System administration and maintenance procedures.

15.1.3 The LPT Processor shall ensure that file systems and the databases always have adequate space available.

15.1.4 The LPT Processor shall monitor LPT System resources including CPU usage, memory usage, network performance, and swap space.

15.1.5 The LPT Processor shall provide LPT System software maintenance, LPT System hardware maintenance, as well as any third party hardware and software maintenance contracts.

16 Disaster Recovery/Business Continuity

General Disaster Recovery/Business Continuity Requirements 16.1

16.1.1 The LPT Processor shall ensure continuous ongoing operations in the event of a disaster or other event that disrupts regular business operations.

16.1.2 The LPT Processor shall provide to OTA a comprehensive Disaster Recovery/Business Continuity plan detailing the process for continued LPT operations and performance of critical business functions in the event of an unscheduled service disruption regardless of the duration.

16.1.3 The LPT Processor shall ensure that a OTA approved Disaster Recovery/Business Continuity Plan is in place and fully tested and approved prior to Go-Live.

Page 42 of 111

16.1.4 The Disaster Recovery/Business Continuity plan shall include, but not be limited to, the following:

Events and situation that will trigger the Disaster Recovery/Business 16.1.4.1Continuity process

Process management 16.1.4.2

Contact list and notification process 16.1.4.3

Methodology for the full recovery of key components of the LPT System 16.1.4.4within required time periods

Plan/alternative for resuming external interfaces and communications 16.1.4.5

Staffing 16.1.4.6

Off-site storage of all LPT System software, documentation, agreements and 16.1.4.7data

Technical and operations support 16.1.4.8

Routine off-site back-up 16.1.4.9

Data recovery/restoration 16.1.4.10

Alternate sites 16.1.4.11

A new LPT System 16.1.4.12

Transfer of critical functionality to a new LPT System capable of running 16.1.4.13the identical (or recovered) operating systems, applications, and databases

Customer notification 16.1.4.14

Test program 16.1.4.15

Return to normal operations 16.1.4.16

16.1.5 The LPT Processor shall ensure that all necessary measures are in place to implement any and all elements of the Disaster Recovery/Business Continuity Plan as needed throughout the Term.

16.1.6 In the event of a disaster or interruption in business services the LPT Processor shall implement the Disaster Recovery/Business Continuity Plan. When the event is over, the LPT Processor shall document lessons learned and update the Disaster Recovery/Business Continuity Plan in accordance with those lessons.

Page 43 of 111

16.1.7 The LPT Processor shall prepare and perform periodic tests of its Disaster Recovery/Business Continuity Plan.

16.1.8 Authorized OTA staff shall be provided complete access to observe all Disaster Recovery/Business Continuity test activities.

16.1.9 At the completion of each test, the LPT Processor shall submit to OTA, a comprehensive report detailing the results of all tests and any corrective actions required with specific timeframes for completions.

16.1.10 The LPT Processor shall update the Disaster Recovery/Business Continuity Plan at least once per year and within 30 days of any major LPT System or hardware change and/or after a disruption in business.

16.1.11 Following are the recovery time standards:

Call center 72 hours 16.1.11.1

Payment processing 72 hours 16.1.11.2

Correspondence 5 Business Days 16.1.11.3

Reporting 5 Business Days 16.1.11.4

Finance tasks 5 Business Days 16.1.11.5

LPT System functions* 72 hours 16.1.11.6

*LPT System functions include, but are not limited to, the following. • Transaction processing

• Website

• CSR access to all screens and functions

• Image Review

• Remote access by OTA to all screens and functions

• Invoice and violation notice generation

• All invoice and violation notice generation related activities

16.1.12 All data shall be backed up at an off-site location such that it can be completely restored on an identical LPT System. This process shall ensure that no data is lost in the event of a LPT System malfunction, disaster or malicious interference with the LPT System.

Page 44 of 111

16.1.13 LPT System disaster recovery operations shall allow for the complete restoration of the LPT System.

17 Documentation

Policies and Procedures Review 17.1

17.1.1 The LPT Processor shall develop and maintain Policies and Procedures documents that define all ongoing operational policies, procedures and processes of the LPT Operation.

17.1.2 The Policies and Procedures documentation shall include operating policy, approved Business Rules and specific procedures required in the performance of all LPT activities, including a detailed description of transaction and data flow processing.

17.1.3 The Policies and Procedures shall encompass all operations covered by the LPT Processor and its third-party contractors (e.g., mail house), including all daily responsibilities and periodic tasks.

17.1.4 The Policies and Procedures shall include:

All LPT program policies 17.1.4.1

All LPT Processor procedures 17.1.4.2

All customer materials and correspondence and the policy for their use 17.1.4.3

Dispute Matrix 17.1.4.4

Customer Authentication Matrix 17.1.4.5

All scripts for common customer service functions, automated recordings, 17.1.4.6and the detailed IVR system menu tree and script

Image review business rules 17.1.4.7

Web page layouts, content and links 17.1.4.8

Samples of all reports, spreadsheets, and reconciliations 17.1.4.9

All required processing timelines 17.1.4.10

All Performance Standards and measurement methods 17.1.4.11

LPT Processor information technology procedures for network 17.1.4.12management, database management, server and PC patching and security.

Legal constraints 17.1.4.13

Page 45 of 111

Privacy handling and other applicable internal controls 17.1.4.14

PCI compliance information 17.1.4.15

Data security 17.1.4.16

17.1.5 The Policies and Procedures shall reflect configurations and LPT System functionality from the current RTM and SDD.

17.1.6 The Policies and Procedures shall include the LPT Processor’s process and schedule for updating and amending all operations documentation on an on-going basis, including but not limited to the Policies and Procedures, user manuals, and disaster recovery plan.

17.1.7 In accordance with the approved Project Schedule, the LPT Processor shall deliver preliminary Policies and Procedures documents.

17.1.8 After receipt of comments from OTA, the LPT Processor shall, as requested by OTA, participate in working sessions with OTA to review the preliminary Policies and Procedures.

17.1.9 The LPT Processor shall incorporate all revisions, as appropriate, based on comments and input from the working sessions and deliver updated Policies and Procedures documents to OTA for review and approval.

17.1.10 An updated version of the Policies and Procedures shall be provided to OTA for approval on an annual basis or in advance of any material policy or procedural change, or more often as requested by OTA.

Manuals 17.2

17.2.1 The LPT Processor shall develop and provide a complete set of LPT System documentation and user/training manuals in electronic and hardcopy format.

17.2.2 The LPT Processor shall provide user/training manuals for different user types such as, but not limited to, CSRs, image reviewers, system administrators, payment processors, auditors, and accounting staff.

17.2.3 The manuals shall include instructions for the use of the relevant aspects of the LPT System, report access levels and descriptions of reports relevant to each user type.

17.2.4 The LPT Processor shall provide administration manuals for the website and the IVR system.

17.2.5 The LPT Processor shall provide a separate Reports User Manual that includes directions for using the ad hoc reporting system.

Page 46 of 111

17.2.6 The LPT Processor shall provide to OTA comprehensive data dictionaries of all CSC databases including descriptions and information about relationships, keys, relational and validation constraints for fields, indexes, tables, views, schemas, triggers, procedures, materialized views, scheduled jobs, directories and any other relevant database objects.

17.2.7 The LPT Processor shall provide and obtain OTA approval of training manuals prior to the start of training.

17.2.8 The LPT Processor shall provide all approved manuals to OTA at least one month prior to Go-Live. In addition, an updated version of all manuals shall be provided to OTA for approval on an annual basis, upon any material change, or more often as requested by OTA.

18 Administrative Requirements

General Administrative Requirements 18.1

18.1.1 The LPT Processor shall be responsible for the administration, management, performance and maintenance of all LPT activities.

18.1.2 The LPT Processor shall have up-to-date knowledge of the regulations and laws relative to the Project and ensure that the LPT operation is in compliance with those regulations and laws.

18.1.3 The LPT Processor’s CSC staff shall not engage in any other business activities while acting in this capacity.

18.1.4 As directed by OTA, the LPT Processor shall research, compile and provide data to OTA in response to Oklahoma Opens Records Requests, subpoenas, search warrants, law enforcement requests or other requests. The LPT Processor shall track, document and report to OTA the status of all such requests on a monthly basis.

18.1.5 The LPT Processor shall be responsive to all OTA inquiries for information, research, and other queries during normal business hours and shall have a process available for responding to emergency queries after normal working hours.

Staffing 18.2

18.2.1 The LPT Processor shall provide qualified personnel sufficient in quantity and expertise and experience to meet the requirements of this Scope of Services and in compliance with an approved Staffing Plan.

18.2.2 The LPT Processor shall name individuals to positions identified and described in its organization chart as Key Personnel.

18.2.3 LPT Processor personnel that interact directly with the public shall perform in a professional manner at all times.

Page 47 of 111

18.2.4 The LPT Processor shall be responsible for all staffing requirements necessary to support the full operation of the LPT Operation, except as specifically indicated, and to meet or exceed all required Performance Standards.

18.2.5 The LPT Processor shall conduct a criminal background check of all License Plate Tolling Processor’s staff immediately prior to employment. The LPT Processor shall certify to OTA that all staff has passed the required background checks.

18.2.6 All staff shall have the appropriate skill, training, background, knowledge, experience, integrity and character necessary to provide the required services in a competent and professional manner.

18.2.7 All LPT Processor staff that interface with the public shall be able to communicate in the English language.

18.2.8 The LPT Processor shall remove any staff member whose qualifications or conduct, in the opinion of OTA, is not appropriate or commensurate with their position.

18.2.9 The LPT Processor shall be responsible for all wages and payroll expenses associated with staffing the License Plate Tolling Operation. Staff of the LPT Processor and/or its Subcontractors and suppliers shall not be considered employees of OTA.

Training 18.3

18.3.1 The LPT Processor shall establish and implement a training program for each position and function.

18.3.2 The LPT Processor shall attend annual security awareness training as prescribed by Payment Card Industry Data Security Standards (PCI DSS) requirements.

18.3.3 All staff shall be fully and properly trained prior to working on the Project. In addition to initial training, all staff shall be informed of any changes to the OTA LPT Program and/or any situations that affect the public and shall be provided instructions and scripts on communicating those changes in a consistent manner.

18.3.4 The LPT Processor shall provide formal CSR training prior to changes to the LPT System that impact the CSR’s use of the LPT System.

18.3.5 The LPT Processor shall notify OTA at least one week prior to all scheduled training so that up to three OTA representatives may observe, monitor or participate in any and all training courses or seminars.

18.3.6 The LPT Processor shall provide training to OTA staff on the use of CSR screens, finding and using standard reports, generating ad-hoc reports, the structure of the database, LPT Policies and Procedures or other topics determined to be of utility to OTA staff.

Page 48 of 111

18.3.7 The LPT Processor shall provide training that utilizes both classroom training and hands on LPT System training, sufficient to ensure that LPT Processor and OTA staff are proficient in the use of the LPT System.

18.3.8 The LPT Processor shall develop and provide all materials, equipment, and facilities required for training.

18.3.9 The LPT Processor shall ensure that all training programs reflect current Policies and Procedures and identify the responsibilities of each employee with regard to theft, fraud, embezzlement, fiscal misconduct, customer confidentiality and/or violation of OTA and LPT policies.

Document Control 18.4

18.4.1 The LPT Processor shall control and keep current all manuals and documents related to LPT operations.

18.4.2 All incoming and outgoing customer correspondence shall be electronically associated with customer accounts and available online in the customer account.

18.4.3 The LPT Processor shall keep all records and reports related to LPT operations in accordance with the data retention requirements.

18.4.4 The LPT Processor shall safely and securely store all documents, e.g. applications, customer correspondence, forms, financial documents and any documents generated or received by the LPT Processor.

18.4.5 The LPT Processor shall file stored documents in a manner that facilitates easy retrieval by subject, type and/or date. Following the period of storage, the LPT Processor shall be responsible for the timely, secure destruction and disposal of documents.

18.4.6 All documents subject to destruction shall be mechanically shredded or turned over to a professional document disposal service.

18.4.7 The LPT Processor shall notify OTA at least 30 days prior to the scheduled destruction of any stored document and the LPT Processor shall notify OTA once the documents have been destroyed.

18.4.8 The LPT Processor shall not destroy any documents or files without the written consent of OTA.

Customer Information and Privacy 18.5

18.5.1 The LPT Processor shall consider all LPT data as confidential and maintain all data in a secure manner that protects personal identification/identity information using state of the art data security measures.

Page 49 of 111

18.5.2 All customer information is confidential and shall not be disclosed or released unless requested by the specific customer or unless directed by OTA.

18.5.3 The LPT Processor shall refer all external requests, inquiries, subpoenas and other official information requests to designated OTA management staff. OTA shall be immediately notified of such requests.

18.5.4 The LPT Processor shall not communicate, respond to inquiries, or provide information to the media, other government agencies, or individuals representing organizations other than in the normal course of customer service.

18.5.5 The LPT Processor shall immediately notify OTA of all requests that are outside of the normal course of customer service.

18.5.6 Responding to all inquiries and communications, other than in the normal course of customer service, will be the responsibility of OTA unless the LPT Processor is specifically directed by OTA to respond.

18.5.7 The LPT Processor shall establish and implement reasonable methods to verify the identity of customers prior to release of information. A customer authentication matrix, detailing the various levels of information that can be released based on authentication level, shall be developed by the LPT Processor, approved by OTA and included in the Policies and Procedures.

18.5.8 The LPT Processor shall not sell, use, or distribute general or specific customer information and data externally for any reason, nor shall it aggregate the data for any non-permitted use.

18.5.9 The LPT Processor shall handle all customer and account information in accordance with the OTA privacy policy, and approved customer account terms and conditions.

18.5.10 Destruction shall be documented and periodically reported to OTA.

18.5.11 A written procedure to ensure proper destruction of customer data in accordance with OTA policy shall be included in the Policies and Procedures developed by the LPT Processor and approved by OTA. The procedure shall define who is responsible for executing the applicable information purges, a method for recording/documenting when purges occur, who is responsible for recording the action and where records of the purge are maintained.

Agency Access 18.6

18.6.1 The LPT Processor shall provide authorized OTA staff with remote, real time, secure, browser-based access into the LPT System to provide customer service, research issues, run reports and perform quality assurance/audit reviews.

Page 50 of 111

18.6.2 The LPT Processor shall provide OTA with various levels of user access privileges commensurate with OTA staff job requirements. The specific access levels shall be defined during the design phase.

18.6.3 OTA remote access shall include, but not be limited to:

Read only access to account data within the LPT System. 18.6.3.1

The ability to input search criteria and perform account information and 18.6.3.2research queries and searches.

The ability to insert notes into customer accounts. 18.6.3.3

The ability to correct or override entries or postings. 18.6.3.4

The ability to generate and retrieve reports in all required formats. 18.6.3.5

Ad-hoc reporting capabilities with full access to the Reporting Database. 18.6.3.6

The ability to print all reports remotely to any printer. 18.6.3.7

Dashboard access. 18.6.3.8

18.6.4 Authorized OTA users shall be issued user names and passwords in accordance with the established LPT System account access rules.

18.6.5 Authorized OTA staff shall have full access (announced and unannounced) to the LPT Processor’s offices and operation for any purpose including quality assurance, internal audit, and observation and monitoring.

18.6.6 The LPT Processor shall provide OTA with workspace (chair and desk) and network access in those offsite facilities in the event that OTA representatives visit those facilities.

18.6.7 OTA shall have the right to inspect the facilities at any time and require the LPT Processor to correct any condition that, in the opinion of OTA, represents safety and/or security concerns and/or is not in keeping with OTA’s public image.

18.6.8 The LPT Processor shall have staff available to support OTA staff by demonstrating and explaining systems and procedures, and answering questions.

19 LPT Physical location

General LPT Physical location Requirements 19.1

19.1.1 The LPT Processor is responsible for establishing, furnishing, supplying, maintaining, staffing, sizing and operating all facilities as needed to meet the requirements of this Scope of Services.

Page 51 of 111

19.1.2 The LPT Processor shall establish, furnish, supply, maintain, staff, and operate the physical location in accordance with all requirements and Performance Standards.

19.1.3 The LPT physical location shall be of appropriate size to conduct all required LPT operations, house all necessary staff and allow for reasonable expansion and contraction in capacity as the OTA LPT Program evolves.

19.1.4 The LPT Processor shall ensure all locations provided by the LPT Processor are Americans with Disabilities Act (ADA) compliant throughout the Term.

19.1.5 The LPT Processor shall ensure that all locations provided or used by the LPT Processor are professional in appearance and clean.

19.1.6 The LPT physical location shall be available prior to the Production Readiness Test to allow for hiring and training, and to support Production Readiness Testing.

19.1.7 The LPT Processor shall provide all furnishings, fixtures, office equipment, computer hardware, signage, supplies, utilities, building services, and physical security and security related to the operation to all LPT Processor provided facilities.

19.1.8 LPT Processor shall provide and maintain all required connectivity and telephone lines, including connections to OTA, the Host and/or third party networks that provide speed and capacity sufficient to ensure all functions can be performed with no delay and with adherence to all data and privacy security requirements.

19.1.9 The LPT Processor shall ensure all computer hardware is protected by a UPS with surge protection and battery backup.

19.1.10 The LPT Processor shall be responsible for any required build-out and/or leasing of office space.

Physical Security 19.2

19.2.1 The LPT Processor shall be fully responsible for the physical security of the LPT facilities and all related property, assets, data and funds.

19.2.2 The LPT Processor shall utilize security measures and devices including, but not limited to, site access controls, data access controls, safes, vaults, surveillance cameras, environmental controls, data security, inventory security, software security and other tools that will prevent, detect, and/or assist in researching and investigating issues at all LPT locations.

19.2.3 The LPT Processor shall ensure that the physical security controls meet all PCI DSS requirements.

19.2.4 The LPT Processor shall be responsible for the custody of funds and shall provide internal control and security practices to protect the receipt, storage, and transfer of funds.

Page 52 of 111

Operating Hours 19.3

19.3.1 The LPT Processor’s live CSR call center shall be available to customers Monday through Friday (excluding holidays), 08:00 - 16:30 CST.

19.3.2 The IVR and website shall be available 24 hours a day, 7 days a week except for approved scheduled outages for maintenance and system updates.

19.3.3 LPT Processor management staff shall be available during regular hours of operation and shall be available 24/7 to respond to emergency situations.

20 Transaction Processing

General Transaction Processing 20.1

20.1.1 The LPT Processor shall process all transactions received from the Host as described in this document and its appendices.

20.1.2 The LPT System shall process all transactions in accordance with the most recent OTA toll rate schedule, provided by OTA.

Image Review 20.2

The Host will provide the LPT Processor with color images for processing. Following is some detail of the typical images that will be provided.

• Image Resolution: 2448 x 2048 pixels

• Bits Per Pixel: 8 or 14 bits

• Pixels across the license plate: 100-110 pixels high and 210-220 pixels wide

• Image Format: JPG

• Field of View: The cameras cover a 14’-16’ field of view. The telephoto lens pulls this into a typical lane width of 10’-12’ tall at a 24’ distance.

• Number of Images: Up to 12 images

20.2.1 The LPT Processor shall establish and implement a process to correctly identify the license plate number, jurisdiction and plate type of each license plate image provided by OTA. This may include processes such as Optical Character Recognition (OCR), fingerprinting and manual image review.

20.2.2 The LPT Processor’s image review process shall achieve a license plate (number, jurisdiction and plate type) accuracy rate of 99.95% of all readable images.

20.2.3 The LPT Processor shall perform image review for all images by processing the oldest transaction date first.

20.2.4 The LPT System shall allow users to perform image enhancements to improve the readability of images.

Page 53 of 111

20.2.5 The LPT System shall allow users to simultaneously view all images related to a particular transaction.

20.2.6 The LPT Processor shall assign an appropriate reject reason, based on a list of reject codes and processing rules to be developed with OTA, to all transactions for which viable license plate information cannot be determined from the available images.

20.2.7 The LPT System shall allow for a minimum of 10 distinct image reject codes, to be defined with and approved by OTA during the design stage.

20.2.8 The LPT System shall reconcile the reject codes to OTA at the transaction level, for all transactions that are rejected.

20.2.9 The LPT System shall allow rejected images to be reviewed for quality assurance purposes.

20.2.10 The LPT Processor shall monitor and report on the quality of images received from the lane system in a manner that allows for the quick escalation of in-lane camera issues to OCR issues.

20.2.11 The LPT System shall automatically queue all previous DMV rejects images for manual re-review, based on a configurable number of retries per transaction.

20.2.12 The LPT System shall allow the number of image review retries to be set to zero.

20.2.13 The LPT Processor shall associate the observed license plate number, plate type (where applicable), and jurisdiction to all transactions for which those data can be determined from the available images.

20.2.14 The LPT Processor shall provide Image Review reports to be developed with OTA during the design stage.

20.2.15 The LPT Processor shall document and adhere to Image Review Policies and Procedures that will be developed with and approved by OTA.

20.2.16 The LPT Processor shall retain all images, including rejected images, according to OTA’s data retention policy.

LPT Watch List 20.3

OTA will refer to the set of vehicle records defined by the requirements in this section as the “Watch List”. 20.3.1 The LPT System shall maintain a manual list of license plate / vehicle information

(string, jurisdiction, and type) records.

20.3.2 The LPT System shall allow authorized LPT Processor and OTA users to access the Watch List and add/remove records.

Page 54 of 111

20.3.3 The LPT System shall require all transactions with license plate information matching to a Watch List record to go through the manual image review process, regardless of the OCR confidence data associated with the transaction/images.

PIKEPASS Account Match Processing 20.4

OTA will provide the LPT Processor with read access to the vehicle information for active PIKEPASS accounts. Transactions that are associated with a vehicle listed on an active PIKEPASS account are eligible to be posted by OTA to a PIKEPASS account (V-Toll) via the PIKEPASS account match process. Therefore, these transactions will not go through regular LPT processing. After identifying V-Toll eligible transactions, a file identifying these transactions will be sent by the LPT Processor to OTA for processing by OTA.

20.4.1 The LPT System shall compare each license plate associated with a transaction to the current list of V-Toll eligible license plates to determine the appropriate method for processing each transaction.

20.4.2 The LPT System shall send all V-Toll eligible transactions to OTA for processing.

20.4.3 The LPT System shall process all other (not V-Toll eligible) transactions as described in this document.

20.4.4 The LPT System shall reconcile these V-Toll eligible transactions back to OTA.

20.4.5 The LPT System shall not process V-Toll transactions to LPT accounts.

Name and Address Acquisition via Registered Owner of Vehicle (ROV) Lookup 20.5

20.5.1 The LPT Processor shall establish and implement a process for using license plate number, issuing jurisdiction, and plate type (where applicable) to obtain the name and address of the registered owner of vehicles from the appropriate DMV and/or other third party services in all 50 states, Washington D.C., all Canadian Provinces, and all Mexican states where possible.

20.5.2 For license plates that cannot be processed to a PIKEPASS account, the LPT System shall access an OTA database to obtain Oklahoma, Texas and Commercial vehicle registered owner name and address information.

20.5.3 For license plates outside of Oklahoma and Texas that cannot be processed to a PIKEPASS account the LPT System shall submit vehicle information to the ROV source for registered owner name and address information.

20.5.4 The LPT Processor shall utilize plate type (DMV categorization of license plates) in its submissions for all states that require or accept plate type as a means of ensuring the highest and most accurate return rate.

Page 55 of 111

20.5.5 The LPT Processor shall be capable of submitting requests to several DMV databases where applicable (for example, individual, commercial, apportioned) to ensure the highest and most accurate return rate.

20.5.6 The LPT Processor may utilize the OTA out-of-state ROV look up vendor.

20.5.7 When multiple transactions for the same license plate information require ROV lookup at the same time, the LPT Processor shall initiate only one request for that particular plate and apply the results to each transaction, if doing so will reduce costs incurred by OTA.

20.5.8 The LPT Processor shall track all DMV and other source requests to their disposition, including hits, no hits, rejected license plates and no responses by state/province and by source.

20.5.9 For transactions that reject or receive no response from an ROV source lookup, the LPT Processor shall use other ROV sources and methods available (e.g., skip tracing) to attempt to locate the responsible owner, in accordance with Policies and Procedures to be approved by OTA.

20.5.10 The LPT Processor shall report to OTA the specific reasons for all failures to obtain the ROV, including by source, reason, jurisdiction, and plate type and with an indication of whether the request was a first submission, resubmission, or was never successfully submitted.

20.5.11 The LPT Processor shall use methods or services approved by OTA to perform uniform address cleansing of data returned from ROV sources.

20.5.12 The LPT System shall have the ability to allow authorized users to override the address field based on approved customer requests.

20.5.13 The LPT System shall associate the information related to the ROV request to the transaction(s) for which that lookup was initiated.

20.5.14 The LPT System shall associate the ROV information returned for a particular lookup with the transaction(s) for which that lookup was initiated.

LPT Transaction Processing 20.6

20.6.1 When the LPT System obtains ROV information for a transaction, the LPT System shall check existing unregistered LPT accounts (UPAs) for an exact match to the name, address, and vehicle information.

20.6.2 If the LPT System identifies an existing UPA with an exact match for the name, address, and license plate information, the LPT System shall process the transactions to that UPA.

Page 56 of 111

20.6.3 If the LPT System identifies an existing UPA with an exact match for the name and license plate information, but a different address, the LPT System shall update the address on that UPA and process the transaction to that account.

20.6.4 If the LPT System determines there is no existing UPA with the exact license plate information and registered owner name, the LPT System shall establish a new UPA for the license plate and ROV information and process the transaction to the new account.

LPT Invoice Account Establishment 20.7

20.7.1 The LPT System shall automatically create new UPAs as dictated by the transaction processing requirements.

20.7.2 The LPT System shall not allow customers or LPT Processor staff to manually establish or close an UPA.

20.7.3 The LPT System shall assign new UPA account numbers sequentially, in order of establishment.

20.7.4 The LPT System shall not allow any UPA to have the same account number as any other UPA or PIKEPASS account.

20.7.5 The LPT System shall use the license plate information associated with a transaction and the ROV information returned by the ROV source to populate the new UPA.

20.7.6 The LPT System shall issue an OTA-approved ‘welcome letter’ to the name/address returned by ROV lookup after the LPT System establishes a new UPA. The timing of issuing the welcome letter will be determined during design.

21 Invoice Generation and Escalation

Invoice Generation and Issuance 21.1

21.1.1 The LPT System shall accumulate LPT transactions on each UPA and generate an invoice for unpaid amounts at the end of the configurable invoice cycle.

21.1.2 The LPT System shall allow for the configurable invoice cycle for the initial invoice to be different than the configurable invoice cycle for all subsequent invoices.

21.1.3 The LPT System shall generate the initial invoice on a new UPA after the end of the initial invoice cycle.

21.1.4 The LPT System shall generate all subsequent invoices (after the initial) for an UPA after the end of the invoice cycle.

21.1.5 The LPT Processor shall have the ability to issue invoices to an email address on file with an UPA, in place of a paper mailing, for accounts opted-in for emailed invoices.

Page 57 of 111

21.1.6 The LPT Processor shall have the capability to provide a link within invoice emails, providing customers access to their online invoice and payment options, with the required credentials for web access.

21.1.7 The LPT System shall allow CSRs to flag accounts (opt-in) for email invoice delivery, upon customer request and according to Policies and Procedures to be approved by OTA.

21.1.8 The LPT Processor shall be capable of selecting accounts with invoices eligible for inclusion of supplemental materials by account variables such as zip code, toll activity, fees, and account status.

Invoice Issuance Suppression 21.2

21.2.1 The LPT System shall provide the functionality to suppress the issuance of invoices with outstanding amounts below a configurable threshold specified by OTA.

21.2.2 The LPT System shall provide functionality to suppress the issuance of invoices for particular accounts, at the account level, at the request of OTA.

21.2.3 The LPT Processor shall provide the functionality to suppress the issuance of invoices with no toll or financial activity during the invoice period.

21.2.4 For accounts with invoice issuance suppressed, the LPT System shall generate the invoice data and associate it with the account but shall not issue the invoice (via mail or email).

21.2.5 The LPT System shall clearly indicate in the account record whether the account has invoice issuance suppressed, along with the reason for that suppression.

21.2.6 The LPT System shall suppress customer mailings that are returned as undeliverable after a configurable number of mailing attempts to the same address.

21.2.7 The LPT System shall have the capability to manually override mail suppression at the account level.

21.2.8 For accounts with invoice mailing suppressed due to returned/undeliverable mail, the LPT System shall have the capability to escalate unpaid amounts.

Invoice Layout Requirements 21.3

21.3.1 On each invoice, the LPT Processor shall provide individual transaction details, including time, date, toll location, vehicle class, license plate information, and toll amount.

21.3.2 The LPT Processor shall display all toll transaction times in Central Time.

Page 58 of 111

21.3.3 On each invoice, the LPT Processor shall have the ability to include UPA-specific data, including but not limited to:

invoice date 21.3.3.1

invoice period 21.3.3.2

invoice number 21.3.3.3

PIN for IVR/web access 21.3.3.4

due date 21.3.3.5

registered owner name 21.3.3.6

registered owner mailing address 21.3.3.7

amount due (new tolls due and total due) for the current invoice cycle 21.3.3.8

amounts due from prior invoice cycles (tolls and fees) broken down by 21.3.3.9invoice cycle

amounts due broken down by past due time periods (e.g., past due, 30 21.3.3.10days past due, 60 days past due)

amount in collections 21.3.3.11

payments received since the issuance of the prior invoice 21.3.3.12

amounts in violation status (by violation notice level, 1st and 2nd) 21.3.3.13

vehicle registration stop flag status 21.3.3.14

21.3.4 On each invoice, the LPT Processor shall have the ability to include general information, including but not limited to:

Customer Service telephone number 21.3.4.1

Customer Service website URL 21.3.4.2

payment instructions 21.3.4.3

PIKEPASS account information 21.3.4.4

escalation timelines and penalties 21.3.4.5

applicable laws and legal means available to OTA for collecting unpaid tolls 21.3.4.6

dispute instructions 21.3.4.7

Page 59 of 111

21.3.5 The LPT Processor shall have the ability to include a barcode that uniquely identifies the invoice.

21.3.6 The LPT System shall support a distinct document layout for invoices that include tolls only.

21.3.7 The LPT System shall support a distinct document layout for invoices that include fees.

21.3.8 The LPT System shall support a distinct document layout for invoices that include violations.

21.3.9 The LPT System shall support a distinct document layout for invoices issued for UPAs with a vehicle registration stop flag placed.

21.3.10 The LPT System shall support a distinct document layout for invoices issued for UPAs with amounts due open with a Collections agency.

21.3.11 The LPT Processor shall work collaboratively with OTA in the design, format and content of all invoices (email and paper), envelopes, and any related materials or inserts during the design phase and subject to the approval of OTA.

21.3.12 The LPT Processor shall be capable of inserting (for paper statements) or attaching (for email statements) other materials in or with selected customer statements as directed by OTA.

Customer Fees 21.4

21.4.1 The LPT System shall allow for the assessment of customer fees.

21.4.2 The LPT System shall allow all fee amounts and the timing of assessment to be configurable.

21.4.3 The LPT System shall provide for all fee amounts to be separately configured.

21.4.4 The LPT System shall allow authorized users to reverse and/or adjust any fee.

Invoice Escalation 21.5

The LPT System accumulates LPT transactions on each UPA and generates an invoice at the end of the invoice cycle.

21.5.1 The LPT System shall set an invoice payment due date for each invoice (a configurable number of days from that particular invoice’s issuance date) that will be visible to customers on their invoices.

21.5.2 The LPT System shall include an invoice payment “grace period” (a configurable number of days from an invoice due date) that will not be visible to customers. The invoice escalation process shall be based on the amounts that are unpaid at the end of the grace period.

Page 60 of 111

21.5.3 The LPT System shall process amounts that remain unpaid for a particular invoice cycle through the escalation process independent of unpaid amounts from other invoice cycles.

21.5.4 The LPT System shall include tolls that are not paid in full at the conclusion of the grace period on the next month’s invoice, and shall assess a late fee (configurable amount) for those outstanding tolls.

21.5.5 The LPT System shall escalate all tolls and fees that appeared on the Unpaid Invoice at the same time, prior to generation of the New Invoice, regardless of the occurrence date or posting date of any particular toll or fee.

21.5.6 The LPT System shall be able to accommodate the invoice/violation escalation process detailed in Table 2. The exact escalation process and related timing will be defined during the design phase.

Table 2 provides an example of the escalation process for one set of tolls accumulated for one invoice cycle.

Table 2: Escalation Process

* For this example the Status is based on an invoice due date plus grace period, totaling 30 days.

Escalation Level Escalation Process Status*

Level A Invoice This is the first time the transactions and related tolls appear on an invoice. Tolls are due at the end of the Grace Period. No fees assessed.

Current

Level B Invoice Tolls that remain unpaid at the conclusion of the Level A Grace Period shall escalate to Level B. This is the 2nd time these tolls are appearing on an invoice. A late fee is assessed prior to generation of this invoice and is included on the invoice.

Past Due 1 Day

Level C Invoice Toll/fee amounts that remain unpaid at the conclusion of the Level B Grace Period shall escalate to Level C. This is the 3rd time these tolls are appearing on an invoice. No additional fees assessed. The late fee assessed at Level B is carried forward, if unpaid, to Level C and appears on the invoice.

Past Due 32 Days

Page 61 of 111


Level D Invoice Toll/fee amounts that remain unpaid at the conclusion of the Level C Grace Period shall escalate to Level D. This is the 4th time these tolls are appearing on an invoice. Unpaid amounts (tolls and fee) that escalate to Level D are now considered a Violation. Unpaid late fee that was assessed at Level B is carried forward to Level D and appears on the invoice. A Violation fee is assessed prior to generation of the invoice, and the Violation fee appears on the Level D invoice. Violation In addition to the Invoice, a separate 1st Violation Notice is generated and sent via 1st class mail. The 1st Violation Notice includes: Unpaid toll amount, Unpaid late fee that was assessed at Level B, and Violation fee assessed at Level D.

Past Due 63 Days

Page 62 of 111


Level E Invoice Tolls/fees that remain unpaid at the conclusion of the Level D Grace Period shall escalate to Level E. This is the 5th time these tolls are appearing on an invoice. No additional fees are assessed. Unpaid late fee assessed at Level B is carried forward to Level E. Unpaid Violation fee assessed at Level D is carried forward to Level E. A Collection Agency fee is assessed and appears on the Level E invoice. Violation Tolls/fees that remain unpaid at the conclusion of the Level D Grace Period shall escalate to Level E. In addition to the invoice, a separate 2nd Violation Notice is generated and sent via Certified Mail. This includes: Unpaid toll amount, Unpaid late fee that was assessed at Level B, Violation fee that was assessed at Level D, a new Collection Agency fee that is assessed at this level (Level E). Collection Agency Tolls/fees that remain unpaid at the conclusion of the Level D Grace Period shall escalate to the Collection Agency.

Past Due 94 Days

Page 63 of 111


Level F Invoice Tolls/fees that remain unpaid at the conclusion of the Level E Grace Period shall escalate to Level F. This is the 6th time these tolls are appearing on an invoice. No additional fees are assessed. Unpaid late fee that was assessed at Level B is carried forward to Level F. Unpaid Violation fee that was assessed at Level D is carried forward to Level F. Unpaid Collection Agency fee that was assessed at Level E is carried forward to Level F. Violation No additional Violation Notices are issued. No additional Violation fees assessed. Collection Agency The Collection Agency continues to pursue outstanding amounts. Registration Hold A stop flag is placed on the Oklahoma vehicle registration.

Past Due 125 Days

Level G and Beyond

Invoice Tolls/fees that remain unpaid at the conclusion of the Level F Grace Period shall be included on subsequent invoices until they are paid or written off by OTA.

Past Due 125 + Days

21.5.7 The LPT System shall allow for all unpaid amounts to display on an invoice broken down by invoice period and escalation level.

21.5.8 The LPT System shall have the capability to assess all past due and escalation fees at any stage in the escalation process.

21.5.9 The LPT System shall have the capability to assess past due and other escalation-related fees.

21.5.10 The LPT System shall have the capability to change where escalation fees are assessed in the escalation process.

Page 64 of 111

21.5.11 The LPT System shall have the capability to assess a violation fee for any invoice escalated to a violation.

21.5.12 The LPT System shall reflect associated fees on invoices, violation notices, and other correspondence as appropriate.

21.5.13 The LPT System shall allow for the assessment of configurable invoice late fees at the transaction level and the invoice level.

21.5.14 The LPT System shall allow for unpaid tolls and fees to be grouped, escalated and displayed on invoices by the period for which they were originally invoiced.

21.5.15 The LPT System shall allow for violations to be included on invoices as well as being issued as a separate violation notice.

21.5.16 The LPT System shall allow for a separate violation notice to be generated and issued for tolls and fees due for each invoice period.

21.5.17 The LPT System shall only generate and issue a violation notice if the violation amounts due are in excess of a configurable minimum amounts. The configurable minimum amounts shall be separate for tolls and fees.

21.5.18 The LPT System shall allow for the escalation of amounts due to an OTA specified Collection Agency.

21.5.19 The LPT System shall escalate amounts due to the Collection Agency only if the amounts due are in excess of a configurable minimum amounts. The configurable minimum amounts shall be separate for tolls and fees.

21.5.20 The LPT System shall allow for the assessment of a Collection Agency fee.

21.5.21 The LPT System shall allow for the assessment of a configurable Collection Agency fee that is based on a percentage of the total amounts due, a flat fee for the invoice period and/or a per-transaction fee.

21.5.22 The LPT System shall allow for a vehicle registration Stop Flag to be placed on Oklahoma license plate with amounts due in excess of configurable minimum amounts. The configurable minimum amounts shall be separate for tolls and fees.

21.5.23 The LPT Processor shall have a process to perform DMV registration holds or other OTA enforcement methods allowed by interstate interoperability enforcement agreements. The details of this process shall be determined during the design phase.

21.5.24 The LPT System shall allow for the write-off of unpaid tolls and/or fees as dictated by the OTA-approved Policies and Procedures.

21.5.25 The LPT System shall have the ability to prevent disputed transactions from escalating until the dispute has been resolved.

Page 65 of 111

22 Violation Processing

Violation Processing 22.1

22.1.1 The LPT Processor shall be responsible for all violation processing, including the generation and issuance of violation notices and applicable correspondence, payment processing, and all related customer service activities per the Oklahoma legislation (Appendix G).

22.1.2 The LPT System shall visually indicate to users whether an UPA has any outstanding amount due that has escalated to violation processing.

Violation Notice Generation and Issuance 22.2

Note that LPT violations are unpaid invoice amounts, per Oklahoma legislation, and there is not necessarily a one-to-one relationship between toll occurrences and violations. 22.2.1 The LPT Processor shall generate and issue all violation notices for LPT violations.

22.2.2 The LPT Processor shall issue all violation notices in the form of paper notices.

22.2.3 The LPT Processor shall issue paper violation notices even for accounts with invoice mailing suppressed.

22.2.4 The LPT Processor shall issue paper violation notices even for accounts opted-in for email delivery of invoices.

22.2.5 The LPT System shall include a configurable minimum dollar amount required to issue a violation notice.

22.2.6 The LPT System shall have the capability to suppress the issuance of violation notices with outstanding amounts below a configurable threshold.

22.2.7 On each violation notice, the LPT Processor shall have the ability to include the following violation-specific information:

notice date 22.2.7.1

notice due date 22.2.7.2

notice number 22.2.7.3

PIN for IVR/web access 22.2.7.4

time and date for each toll 22.2.7.5

location for each toll 22.2.7.6

axle count for each toll 22.2.7.7

Page 66 of 111

license plate image 22.2.7.8

license plate number and state 22.2.7.9

vehicle make 22.2.7.10

vehicle owner name and address 22.2.7.11

amount due (tolls due, fees due, total due) 22.2.7.12

barcode that uniquely identifies the violation notice 22.2.7.13

22.2.8 On each violation notice, the LPT Processor shall have the ability to include the following general information:

payment instructions 22.2.8.1

escalation information 22.2.8.2

applicable laws 22.2.8.3

PIKEPASS account information 22.2.8.4

OTA website URL 22.2.8.5

dispute information 22.2.8.6

Customer Service telephone number 22.2.8.7

22.2.9 The LPT Processor shall work collaboratively with OTA in the design, format and content of all violation notices, envelopes, and any related materials or inserts during the design phase and subject to the approval of OTA.

22.2.10 The LPT System shall support distinct layouts for 1st violation notices and 2nd violation notices.

Violation Notices Tracking and Resolution 22.3

22.3.1 The LPT Processor shall update the status of each violation and violation notice during its life cycle process so that the LPT Processor and OTA can effectively manage and track violations and violation notices. The LPT Processor shall track the following information:

Payments that result in payment in full, partial payment, or over-payment. 22.3.1.1

Payment reversals due to insufficient funds or chargebacks. 22.3.1.2

Violations disputed or under administrative review. 22.3.1.3

Page 67 of 111

Violations dismissed, negotiated, hearing requested or dispute denied. 22.3.1.4

Vehicle Registration Stop Flags 22.4

Vehicle registration holds / stop flags prevent the renewal of Oklahoma vehicle registrations for vehicle owners with outstanding OTA violations. OTA currently places vehicle registration holds for delinquent violators with Oklahoma license plates in the Oklahoma Tax Commission (Commission) system directly.

22.4.1 The LPT Processor shall develop an interface to the Oklahoma Tax Commission system to automate the transmission of vehicle registration stop flag placement and removal requests to the Commission.

22.4.2 The LPT Processor shall update the stop flag status in real time as the account status changes.

22.4.3 The LPT Processor shall never place a stop flag for outstanding amounts consisting only of fees—there must be some toll amount included.

22.4.4 The LPT System shall track and report on stop flag activity, including placement requests, removal requests, and payments.

22.4.5 The LPT System shall visually indicate to users whether an UPA has amounts due related to a stop flag.

22.4.6 The LPT System shall clearly display to customer service users the total payment amount required to remove the stop flag, for accounts on which there is an active stop flag.

Collection Agency 22.5

OTA currently utilizes a 3rd party collection agency to assist in collection of outstanding tolls and fees related to the PIKEPASS operation. 22.5.1 The LPT System shall interface with the collection agency for the exchange of debt

placements and payment data based on an ICD that shall be developed jointly between the collections agency and the LPT Processor.

22.5.2 The LPT System shall place unpaid tolls and fees with the collection agency based on the approved escalation process.

22.5.3 The LPT System shall only escalate unpaid tolls and fees to the collection agency when are in excess of configurable minimum amounts. The configurable minimum amounts shall be separate for tolls and fees.

22.5.4 The LPT System shall reconcile placements and payments with the collection agency.

22.5.5 The LPT System shall report to OTA the status of amounts placed with the collection agency based on information provided by the collection agency.

Page 68 of 111

22.5.6 The LPT System shall accept, process and track payments made to the LPT Processor for debt placed with the collection agency.

22.5.7 The LPT Processor shall update the collection agency with all payments made for transactions in collections.

22.5.8 The LPT System shall provide reporting on collection agency related violations and payments as required by OTA.

22.5.9 The LPT System shall visually indicate to users whether an UPA has amounts due that have been escalated to the collection agency.

22.5.10 The LPT System shall clearly display to customer service users the total outstanding amount that has been escalated to the collection agency.

23 Payment Processing

General Payment Processing Requirements 23.1

23.1.1 The LPT System shall allow authorized users to process customer payments according to OTA-approved payment processing Policies and Procedures.

23.1.2 The LPT Processor shall develop specific Policies and Procedures for processing partial payments.

23.1.3 The LPT System shall allow for partial payment of invoices and violation notices.

23.1.4 The LPT System shall provide functionality to process partial payments and over-payments.

23.1.5 The LPT System shall apply partial payments to outstanding amounts (all tolls and fees) on a first-in, first-out basis.

23.1.6 The LPT System shall provide an option to allow authorized users to override the first-in, first-out rule and apply payments to user-selected tolls and fees.

23.1.7 The LPT System shall apply invoice overpayment amounts to the account as a prepaid balance for use in a subsequent invoice cycle.

23.1.8 The LPT System shall apply prepaid balances to outstanding amounts (all tolls and fees) on a first-in, first-out basis prior to issuing an invoice. This payment shall be reflected on the invoice.

23.1.9 The LPT System shall allow authorized users to initiate a refund of any prepaid balance amount in accordance with OTA-approved Policies and Procedures (e.g., due to customer request).

Page 69 of 111

23.1.10 The LPT System shall have the capability to assess non-sufficient funds (NSF) fees for returned checks.

24 Account Maintenance and Management

Customer Information and Correspondence 24.1

24.1.1 The LPT System shall support electronically linking documents to accounts, including both incoming and outgoing correspondence.

24.1.2 The LPT System shall ensure all customer correspondence is easily accessible by the LPT Processor and OTA staff in the performance of customer service tasks.

24.1.3 The LPT System shall allow authorized users to enter account notes on any account at any time, and shall store all user-entered notes with the account.

24.1.4 The LPT System shall allow authorized users to enter an email address on an UPA for customer communications.

24.1.5 The LPT System shall allow authorized users to mark an UPA with a valid email address on file as opted-in for emailed invoices.

General Account Management 24.2

24.2.1 The LPT System shall allow authorized LPT staff and authorized OTA users to manage LPT accounts, which shall include the following capabilities:

View posted Transactions 24.2.1.1

View payment history 24.2.1.2

View the account balance 24.2.1.3

View account notes and contact history 24.2.1.4

View documents sent to and received from the customer 24.2.1.5

Attach documents to an account 24.2.1.6

View and modify customer demographics 24.2.1.7

View and modify invoice delivery options 24.2.1.8

View vehicle information 24.2.1.9

View transaction images 24.2.1.10

Add and remove credit/debit card and ACH information 24.2.1.11

Page 70 of 111

Process payments 24.2.1.12

Dispute tolls and fees 24.2.1.13

24.2.2 The LPT System shall not allow modification or removal of the name/address information returned by an ROV source lookup.

Disputes and Adjustments 24.3

24.3.1 The LPT Processor shall establish and implement processes to receive, research, document, and resolve all customer disputes.

24.3.2 The LPT Processor shall develop Policies and Procedures, subject to OTA review and approval, for handling all disputes, including conditions under which OTA approval is required.

24.3.3 The disposition of all disputes shall be communicated to the customer in the same manner as the dispute was received from the customer (e.g., mail, email, telephone).

24.3.4 The LPT Processor shall develop and document, for OTA approval, a dispute escalation process in which certain unresolved disputes shall be escalated to OTA for administrative review.

24.3.5 The LPT Processor shall thoroughly research disputes and provide OTA with all relevant documentation related to disputes submitted for administrative review.

24.3.6 The LPT System shall allow authorized users to adjust tolls, payments, and fees posted to an account, according to approved Policies and Procedures, and with an appropriate audit trail.

24.3.7 The LPT System shall require authorized users to enter account notes for all actions taken in cases of dismissals, disputes, reversals, corrections, and adjustments.

24.3.8 The LPT Processor shall schedule hearings (formal process for disputing violation notices) requested by violation notice recipients and prepare hearing evidence packages. Hearings will be conducted by OTA.

Toll/Fee Dismissal 24.4

24.4.1 The LPT System shall support the ability to dismiss one or more transactions (tolls and/or fees separately).

24.4.2 The LPT Processor shall develop Policies and Procedures, subject to OTA approval, for dismissing tolls and/or fees.

Transfer of Responsibility (TOR) 24.5

24.5.1 The LPT System shall have the capability and the LPT Processor shall establish and implement procedures for the transfer of responsibility for transactions and related

Page 71 of 111

amounts due based on updated vehicle owner information, e.g., rental/leased vehicles or transfer of vehicle ownership.

24.5.2 The LPT Processor shall develop Policies and Procedures for obtaining appropriate evidence to support and validate TOR information.

24.5.3 If the LPT Processor determines that an invoice or violation notice is eligible for a TOR, according to OTA-approved Policies and Procedures, the fees shall be dismissed and the tolls only shall be mailed on a new invoice to the new responsible party’s name and address, restarting the regular escalation process.

24.5.4 The LPT System shall retain a record of the transfer on the original account.

UPA Conversion to PIKEPASS 24.6

24.6.1 The LPT Processor shall work with OTA to develop the procedures and design the functionality required to support conversion of LPT accounts to PIKEPASS accounts. OTA will be responsible for all PIKEPASS development.

24.6.2 The LPT System shall allow UPAs to be converted to PIKEPASS accounts by OTA users accessing the LPT System from the OTA CSC only.

24.6.3 The LPT System shall retain all LPT account history for the converted UPA, including toll and financial transaction history.

24.6.4 The LPT System shall not allow toll or payment transactions to post to any LPT account that has been converted to PIKEPASS. OTA will be responsible for all postings to PIKEPASS accounts established by conversion from LPT accounts.

24.6.5 The LPT System shall not allow PIKEPASS conversion of any LPT account with unpaid violations, past-due tolls, or fees.

24.6.6 The LPT Processor shall require OTA’s authorization to reduce or waive amounts due on an LPT account for the purposes of conversion to a PIKEPASS account.

24.6.7 The LPT System shall provide for functionality that flags financial adjustments as due to PIKEPASS conversion / with OTA authorization.

24.6.8 Upon successful conversion, the LPT System shall update the LPT account with a status indicating the account was converted to PIKEPASS.

25 LPT System Interfaces

External Interfaces 25.1

25.1.1 The LPT Processor shall interface with the following entities and shall collaboratively develop, where applicable, an Interface Control Document (ICD) with each entity to establish communication protocol.

Page 72 of 111

Host system operated by OTA (current ICD is in Appendix E), which 25.1.1.1includes LPT transactions and images, PIKEPASS account match lookups, Oklahoma, Texas and Commercial vehicle License Plate (ROV) lookups, and the HOT list

ACH and credit/debit card processors 25.1.1.2

All required DMVs and/or third party providers who provide vehicle 25.1.1.3registration information

Registration stop flags with the Oklahoma Tax Commission 25.1.1.4

Bank(s) 25.1.1.5

Collection agency 25.1.1.6

25.1.2 The LPT Processor shall coordinate with third parties and update external interfaces as needed.

Host Interface 25.2

OTA will develop a web service interface and allow a secure VPN connection, and corresponding ICD, for the LPT System and the Host to exchange data including LPT transactions, images and reconciliations, PIKEPASS account match look-ups, Oklahoma, Texas and Commercial registered owner vehicle information and HOT lists.

25.2.1 The LPT System shall interface with the OTA Host as detailed in the Interface Control Document.

25.2.2 The LPT Processor shall ensure that all data received via the interface with the OTA Host is properly accounted for and processed in a timely and accurate manner.

25.2.3 The LPT Processor shall coordinate with OTA to setup a Site-to-Site VPN to secure the data exchanges between the LPT System and OTA Host. It shall be an IPsec or equivalent VPN tunnel with a pre-shared key and an agreed upon encryption method.

File Exchanges 25.3

25.3.1 The LPT Processor shall implement system alerts to the LPT Processor and OTA when any scheduled file exchange does not occur within a configurable amount of time or number of attempts/timeouts.

25.3.2 The LPT Processor shall reconcile with the Host at the file level, for all files received.

25.3.3 The LPT Processor shall reconcile transaction files with the Host at the individual transaction level, for each transaction record in the file received.

Page 73 of 111

Transaction Reconciliation 25.4

25.4.1 The LPT Processor shall reconcile transaction statuses to OTA that indicate the current processing status of each transaction received from the Host.

25.4.2 The LPT Processor shall prepare and send reconciliation files on a configurable basis.

25.4.3 The LPT Processor shall provide an updated reconciliation status for a given transaction any time there is a change in its processing status from the last update sent to OTA.

25.4.4 The LPT Processor shall use reconciliation codes to indicate the transaction’s current processing status.

25.4.5 The LPT Processor shall finalize the list of reconciliation codes and associated processing statuses with OTA during the design phase.

25.4.6 The LPT Processor shall update the OTA Host to LPT System ICD with the final list of reconciliation codes. Following are examples of the types of statuses for which the LPT Processor shall provide reconciliation codes.

• Interim – Transaction received by the License Plate Tolling Processor

• Rejected – Duplicate transaction

• Rejected – Rejected by DMV/ROV source

• Rejected – No DMV reciprocity

• Dismissed – OTA request

• Interim – In image review

• Interim – Invoiced

• Interim – Past due invoice

• Interim – Transfer of Responsibility (TOR)

• Final – Dismissed at PIKEPASS request

• Final – Dismissed by LPT Processor

• Final – Dismissed for PIKEPASS conversion

• Final – Paid Invoice PIKEPASS Account Match Lookups 25.5

OTA will provide the LPT Processor with access to a read-only database view, or result set of a stored query of the PIKEPASS data, for use in identifying customer transactions eligible to post to a PIKEPASS account (V-Toll).

Page 74 of 111

25.5.1 The LPT System shall utilize the PIKEPASS data provided by OTA to compare License Plate number and jurisdiction against the PIKEPASS customer database.

25.5.2 The LPT System shall send a file, in an agreed upon format using an interface or file transfer method, the list of Toll Transaction IDs and Image IDs that were found to be PIKEPASS customer transactions.

25.5.3 The LPT System shall request an acknowledgement of receipt and then process the stored transactions and images it sent in the file as dismissed as PIKEPASS or equivalent code.

25.5.4 The LPT System shall track the number of PIKEPASS transactions it finds and provide it in the reconciliation report via the web service with the OTA Host.

Oklahoma License Plate Lookups 25.6

OTA will provide the LPT Processor with access to a read-only database of Oklahoma License Plates and the registered owner of the vehicle (ROV) information.

25.6.1 The LPT System shall query the OTA-provided database of OK License Plate numbers to obtain ROV information for processing tolls.

25.6.2 The LPT Processor shall adhere to OTA data retention and security standards to ensure the PII data received from the OK License Plate database is secure and not breached.

Texas License Plate Lookups 25.7

OTA will provide the LPT Processor with access to a read-only database of the Texas License Plates and the registered owner of the vehicle (ROV) information.

25.7.1 The LPT System shall query the OTA-provided database of TX License Plate numbers to obtain ROV information for processing tolls.

25.7.2 The LPT Processor shall adhere to OTA data retention and security standards to ensure the PII data received from the TX License Plate database is secure and not breached.

Commercial License Plate Lookups (CVIEW) 25.8

25.8.1 OTA will provide the LPT Processor with access to a read-only database of the CVIEW commercial License Plates and the registered owner of the vehicle (ROV) information.

25.8.2 The LPT System shall query the OTA-provided database of CVIEW commercial License Plate numbers to obtain ROV information for processing tolls.

Page 75 of 111

25.8.3 The LPT Processor shall adhere to OTA data retention and security standards to ensure the PII data received from the CVIEW commercial License Plate database is secure and not breached.

Hot Lists 25.9

OTA may wish to periodically send the LPT Processor Hot Lists, which contain a list of license plates for which OTA would like notification if processed by the LPT System. OTA will send the LPT Processor Hot Lists in an agreed upon file format using a defined transfer method. The OTA Host to LPT System ICD will contain detail of the Hot List data exchange.

25.9.1 The LPT System shall process the Hot List and notify OTA via the web service when License Plate matches are found.

Oklahoma Tax Commission 25.10

25.10.1 The LPT Processor shall place vehicle registration stop flags for Oklahoma license plates with the Oklahoma Tax Commission.

25.10.2 The LPT Processor shall coordinate with the Oklahoma Tax Commission to develop an ICD, which shall define an interface to send registration stop flags to the Oklahoma Tax Commission system.

25.10.3 The LPT System shall request acknowledgement via the interface that the stop flag has been applied.

25.10.4 The LPT System shall notify OTA via the daily reconciliation how many LPT customers have stop flags applied.

25.10.5 The LPT System to Oklahoma Tax Commission interface shall also have the ability to release stop flags, and shall subsequently also notify OTA via the daily report of the number of stop flag releases.

25.10.6 The LPT Processor shall remove the stop flag, update the account and reconcile to OTA when a payment issue has been resolved.

Third Party Interfaces 25.11

25.11.1 The LPT Processor shall coordinate with any third party vendor it uses for LPT processing to develop an ICD that defines the interface between the third party and the LPT System.

25.11.2 All ICDs for third party interfaces, including those below, shall follow the same framework as the OTA Host to LPT System ICD in Appendix E.

ACH and credit/debit card processors 25.11.2.1

Page 76 of 111

Bank(s) 25.11.2.2

Collection agency 25.11.2.3

26 Mail Processing

General Mail Processing Requirements 26.1

26.1.1 The LPT Processor shall generate, distribute and track all printed customer correspondence, including materials in the form of letters, notices, invoices and general correspondence.

26.1.2 The LPT Processor shall establish and administer all postal service relationships. The actual cost of postage for outgoing mail shall be a direct pass through cost to OTA with no mark-up.

26.1.3 The LPT Processor shall utilize the extended ZIP+4 Codes in all mailing where available.

26.1.4 The LPT Processor shall track and report on all incoming and outgoing correspondence by type.

26.1.5 The LPT Processor shall implement a process to manage, research, correct, and minimize mail returned as undeliverable.

26.1.6 The LPT Processor shall track and report on mail returned as undeliverable.

Incoming Mail Processing 26.2

Incoming mail may include payments, disputes, returned mail, general administrative mail, and general public inquiries.

26.2.1 The LPT Processor shall establish and implement procedures to provide effective and efficient handling of all incoming mail, including procedures for tracking customer correspondence.

26.2.2 The LPT Processor shall accurately timestamp all incoming correspondence for quality assurance and audit purposes.

26.2.3 The LPT Processor shall provide an appropriate response to all customer inquiries received by mail, according to OTA-approved Policies and Procedures.

26.2.4 The LPT Processor shall scan all incoming mail.

26.2.5 The LPT System shall associate scanned mail related to an LPT account with the account to allow users to view a digital image of the document.

Page 77 of 111

26.2.6 The LPT Processor shall store all scanned mail that is not associated to an LPT account in an electronic file.

Outgoing Mail Processing 26.3

Although mass mailing may be required from time to time, the majority of outgoing mail will be based on specific situations affecting individual customers or groups of customers. 26.3.1 The LPT Processor shall establish and implement a process to provide the timely,

efficient and accurate handling of all outgoing mail.

26.3.2 The LPT Processor shall track the date and time that all outgoing correspondence is mailed for quality assurance and audit purposes.

26.3.3 The LPT Processor shall send all paper customer correspondence via first class mail or better, unless specifically directed by OTA to do otherwise.

26.3.4 The LPT Processor shall send all 2nd violation notices via Certified Mail.

26.3.5 The LPT Processor shall employ bulk mail rates and other mailing economies, where available, including the capacity for pre-sorting mail by Zip Code to ensure the most cost effective postage rates are obtained.

26.3.6 The LPT Processor shall have full responsibility over any mail house services that it may choose to outsource.

26.3.7 The LPT Processor shall establish and implement quality assurance procedures that include the monitoring, spot checking and tracking of all outgoing mail.

26.3.8 The LPT Processor shall generate configurable form letters and individual situational customer correspondence as appropriate.

26.3.9 The LPT Processor shall utilize skip tracing and develop procedures to attempt to obtain an address for all returned mail.

26.3.10 For invoices and violation notices returned by the US Postal Service (USPS) with a forwarding address, the LPT Processor shall reissue the invoice or violation notice to the forwarding address provided by the USPS.

26.3.11 The LPT Processor shall utilize a process for address standardization.

26.3.12 The LPT Processor shall utilize the National Change of Address (NCOA) service.

26.3.13 If the NCOA returns an updated address, the LPT Processor shall reissue the invoice or violation notice to the updated address.

26.3.14 The LPT Processor shall design all customer correspondence with OTA during the design phase. A sample list of the types of customer correspondence envisioned for the LPT program is included below:

Page 78 of 111

• Welcome Letter

• Invoices

• Violation Notices

• Returned Check Letter

• ACH Reject Letter

• Registration Hold Letter

• Sent to Collections Agency Letter

• Dispute Resolution

• Returned Email

• Refunds

• Other Inquiry Response

27 Customer Communications & Materials

Customer Communications 27.1

Customer correspondence includes fixed materials and forms, as well as variable and unique LPT account and situational based communications.

27.1.1 The LPT Processor shall be responsible for all aspects of communication with LPT customers, including communications via telephone, mail, email, web, and fax.

27.1.2 The LPT Processor shall record and maintain an historical record of all customer contacts in the account.

27.1.3 The LPT Processor shall design, produce, inventory, and distribute all customer communications and correspondence as approved by OTA.

27.1.4 The LPT Processor shall answer inquiries from the general public provided the subject is consistent with general information related to the LPT locations and LPT customer service.

27.1.5 The LPT Processor shall not initiate promotional or other unsolicited informational communication with unregistered LPT customers.

Email 27.2

27.2.1 The LPT Processor shall have the capability to receive customer inquiries and requests via email and respond to customer inquiries and requests via email.

27.2.2 The LPT Processor shall send all customer correspondence via email, when provided by and indicated as preferred by the customer, except where hard copies are required.

Page 79 of 111

27.2.3 The LPT Processor shall establish, implement and maintain a process to allow customers to opt-in to receive messages via email.

27.2.4 The LPT Processor shall use industry best practices for handling undeliverable email messages.

27.2.5 The LPT Processor shall develop the format and content of all email messages during the design phase and shall require OTA approval of any changes thereafter.

Social Media 27.3

27.3.1 The LPT Processor shall work with the OTA’s Director of Communications and/or his designee for implementing and maintaining public communications via social media.

27.3.2 The LPT Processor shall obtain OTA authorization and approval of any customer interaction via social media.

27.3.3 The LPT Processor shall work with OTA to identify and disseminate messages and information about the License Plate Tolling program (e.g., monitor social media, notify OTA of issues, and provide recommended responses and feedback when requested by OTA).

IVR System 27.4

27.4.1 The LPT Processor shall establish, operate and maintain an interactive voice response (IVR) system.

27.4.2 The LPT Processor shall utilize IVR system components, including ancillary equipment and software, which are dedicated to the LPT System for use for the License Plate Tolling program.

27.4.3 The LPT IVR system (“LPT IVR”) or subcomponents and software shall not be shared with other co-located/supported LPT Processor clients.

27.4.4 The LPT Processor shall provide a toll-free telephone number for the LPT IVR.

27.4.5 The LPT IVR shall route calls and accept payments via menu selections and user input.

27.4.6 The LPT IVR shall provide customers with the ability to hear amounts due and make payments (via debit/credit cards or ACH) 24 hours per day, 7 days per week.

27.4.7 The LPT IVR shall require appropriate authentication (e.g., an invoice number and access PIN) prior to providing any account specific information.

27.4.8 The LPT IVR shall provide users with an option to be transferred to a CSR during operating hours.

27.4.9 The LPT IVR shall provide customers with the option to be transferred to a Spanish speaking CSR during operating hours.

Page 80 of 111

27.4.10 The LPT IVR shall provide callers who request to be transferred to a CSR with the estimated waiting time to speak to a CSR upon entering the CSR queue and every 60 seconds during their time in queue.

27.4.11 The LPT IVR shall be fully integrated with the functional LPT System.

27.4.12 During non-business hours, the LPT IVR shall announce a message informing callers that the live call center is now closed but customers can make payments via the IVR system and website.

27.4.13 The LPT IVR system shall interact with the LPT System database in real time to retrieve account information.

27.4.14 The IVR system shall utilize a single recorded voice talent and have consistency in volume and intonation, except in certain time sensitive situations as directed and approved by OTA.

27.4.15 The LPT Processor shall obtain OTA approval of the IVR system voice talent and script.

27.4.16 The LPT Processor shall have the ability to remotely make short term, time sensitive changes to the IVR system.

27.4.17 The LPT Processor shall make necessary changes to the IVR script, messages, and menu options at no additional cost to and only upon approval by OTA.

27.4.18 The LPT Processor shall ensure that the IVR system is ADA compliant throughout the Term.

Call Center 27.5

27.5.1 The LPT Processor shall provide call center staff that are dedicated solely to the OTA License Plate Tolling program.

27.5.2 The LPT Processor shall provide all hardware and software for processing incoming customer calls.

27.5.3 The LPT Processor shall have sufficient staff in place during the defined operating hours to handle all inbound callers who wish to speak to a CSR within the time parameters specified in the Performance Standards.

27.5.4 The LPT Processor shall establish and document Policies and Procedures, subject to OTA review and approval, for the escalation of calls and issues to LPT Processor supervisory and management staff, as well as to OTA staff.

27.5.5 The LPT Processor shall track and resolve all escalated issues.

27.5.6 The LPT Processor shall record detailed account notes related to each call.

Page 81 of 111

27.5.7 The LPT System shall document, track and report all IVR system and CSR calls, separately, by specific reason for the call (e.g., dispute, payment).

27.5.8 The LPT Processor shall record the reason(s) for each call via call reason codes that will be established by the LPT Processor and approved by OTA during design.

27.5.9 The LPT System shall provide for input of multiple codes in cases where more than one reason/type code applies to the call.

27.5.10 The LPT System shall provide for, and the LPT Processor shall establish and implement processes for, supervisory monitoring of both live and recorded CSR calls for accuracy, efficiency, professionalism and courteous service.

27.5.11 The LPT Processor shall develop a form to record CSR monitoring activity and shall submit the form to OTA for approval. The LPT Processor shall keep completed CSR monitoring forms on file for a year and submit a monthly summary to OTA.

27.5.12 The LPT Processor shall provide OTA with automated capability to monitor any live customer calls from offsite, at any time without prior notification to the LPT Processor or to the CSR being monitored.

27.5.13 The LPT Processor shall ensure that the phone system announces on all calls that calls may be monitored (e.g., ‘calls may be monitored for quality assurance purposes’).

27.5.14 The LPT Processor shall ensure that the phone system is ADA compliant throughout the Term.

27.5.15 Once a customer call is answered by a CSR, the call shall not be immediately placed on hold to answer another call.

27.5.16 Call center staff shall respond to customer non-LPT related calls (e.g., OTA policies, turnpike operations, PIKEPASS accounts, interoperability, points of customer contact) by providing information in accordance with specific scripts approved by OTA or refer caller to PIKEPASS CSC or website.

28 Website

Website Requirements 28.1

28.1.1 The LPT Processor shall design, develop, implement, host, and maintain an intuitive, user-friendly, and interactive customer website, including the website domain.

28.1.2 The LPT Processor shall provide OTA with a link to the LPT website that can be used on the OTA PIKEPASS website to direct customers to the LPT Processor website.

28.1.3 The LPT Processor shall prominently display a link to PIKEPASS.com for questions and issues not related to License Plate Tolling.

Page 82 of 111

28.1.4 The LPT System database interface to the LPT website shall facilitate the automatic electronic exchange of all required account information supporting all required functionality.

28.1.5 The LPT Processor shall design the website using industry best practices for easy updating and workflow changes and include a content management module that will allow authorized OTA staff to update content without the need for extensive LPT Processor assistance.

28.1.6 The LPT website shall be optimized for, and function properly, on Internet Explorer, Safari, Firefox and Chrome, as well as on multiple platforms including personal computers, mobile devices and tablet devices.

28.1.7 The LPT website shall be secure and require appropriate customer authentication for all account-specific pages.

28.1.8 The LPT Processor shall define and develop the specific look, functionality, and navigation of the website with OTA during the design phase.

28.1.9 The LPT Processor shall ensure that the website is ADA compliant throughout the Term.

Website Account Management 28.2

28.2.1 The website shall provide customer access to account information through a secure login.

28.2.2 Access to customer account data shall require login with an invoice number and license plate number/state, or an invoice number and access PIN.

28.2.3 All customer account activity made via the website shall be immediately reflected in the database and on the customer account screens.

Website Services 28.3

28.3.1 The LPT Processor website shall provide customers with the following functionality:

View current and past invoices 28.3.1.1

View current and past violations 28.3.1.2

View current and past images 28.3.1.3

Pay invoice via credit card, debit card, or ACH 28.3.1.4

Pay violations via credit card, debit card, or ACH 28.3.1.5

Associate an email with the account 28.3.1.6

Page 83 of 111

Opt-in/out of email invoices 28.3.1.7

Opt-in/out of email correspondence 28.3.1.8

Dispute process 28.3.1.9

28.3.2 The LPT Processor shall provide a “Contact Us” feature and various methods to communicate with the LPT Processor via the website, using email or HTML forms.

28.3.3 The LPT System shall acknowledge customer inquiries received via the website via an automated email receipt confirmation to the customer.

28.3.4 The website shall provide static informational pages, including the following:

A description of the LPT program 28.3.4.1

Invoice escalation process including violations, collections and fees 28.3.4.2

Vehicle registration stop flag process 28.3.4.3

Payment information 28.3.4.4

How to sign up for a PIKEPASS account 28.3.4.5

Help and frequently asked question 28.3.4.6

Privacy Policy 28.3.4.7

Downloadable forms and customer guides 28.3.4.8

Links to other sites to be determined by OTA 28.3.4.9

28.3.5 The LPT Processor shall perform all website maintenance and content updates.

Website Security 28.4

28.4.1 The LPT Processor shall institute security measures to prevent unauthorized access to the LPT System, and maintain the confidentiality and security of all customer data subject to applicable federal, state and local laws and applicable financial and banking policies, including Payment Card Industry Data Security Standards (PCI DSS).

28.4.2 The LPT Processor shall maintain proper PCI DSS compliance on the website used for account management throughout the Term.

28.4.3 The LPT Processor shall be responsible for all costs related to maintaining compliance with PCI DSS and any related updates.

28.4.4 The website shall incorporate a firewall, or security appliance, with security functions to prevent unauthorized access to any parts of the LPT System.

Page 84 of 111

28.4.5 The LPT Processor shall use appropriate protocols to ensure secure data transmission from/to the user’s browser.

28.4.6 The website shall utilize secure connection with all confidential communications encrypted Transport Layer Security (TLS) protocol.

28.4.7 LPT Processor shall provide, operate and maintain the website in a manner that adheres to the current industry best practices for website security.

28.4.8 The OTA privacy policy shall be accessible via hyperlink on the footer of every page.

28.4.9 The LPT Processor shall acquire the website security certificate and maintain it in full force and effect throughout the Term.

29 Payment Processing

General Payment Processing Requirements 29.1

29.1.1 The LPT Processor shall securely process all payments received.

29.1.2 The LPT Processor shall accurately track the chain of custody of all payments.

29.1.3 The LPT Processor shall apply all payments to the correct accounts in the LPT System.

29.1.4 The LPT Processor shall establish and implement daily, weekly and monthly reconciliation processes, audit trails and controls to safeguard all funds received.

29.1.5 The LPT Processor shall handle payment adjustments, reversals, refunds, NSF checks, partial payments, overpayments, split payments, and unidentified payments.

29.1.6 The LPT Processor shall establish and implement processes for handling of all payments, including partial payments and overpayments.

29.1.7 The LPT System shall apply payments received without specific customer direction to outstanding customer balances based on OTA approved Policies and Procedures.

29.1.8 The LPT System shall apply partial payments to the oldest tolls/fees first (first-in, first-out) by default.

29.1.9 The LPT System shall provide functionality for users to manually apply partial payments to specific tolls/fees (not first-in, first-out) in accordance with customer instructions or OTA direction.

29.1.10 The LPT Processor shall process, resolve, reconcile, and report unidentified payments (payments not accompanied by information to allow matching to an account).

29.1.11 The LPT Processor shall handle unidentified payments that cannot be resolved in accordance with applicable Oklahoma State escheatment laws.

Page 85 of 111

29.1.12 The LPT Processor shall gather and package all data related to unidentified payments as directed by OTA.

29.1.13 The LPT Processor shall verify that checks are signed and completed properly, and that credit/debit card numbers and signatures are completed properly.

29.1.14 The LPT Processor shall track, handle and report on incomplete payments such as unsigned checks and incomplete credit/debit card numbers.

29.1.15 The LPT Processor shall scan all customer payment correspondence, including the front and back of all checks.

29.1.16 The LPT System shall associate and store images of scanned payment correspondence, including checks, with the appropriate account.

29.1.17 The LPT Processor shall track and report on all payments by location, by user, by posting date, and by payment method.

29.1.18 The LPT Processor shall reconcile all payments posted to bank deposits and credit/debit card/ACH processing receipts on a daily basis.

29.1.19 The LPT Processor shall maintain a record of any discrepancies with bank deposits and report them immediately to OTA.

29.1.20 The LPT Processor shall ensure that all payments are deposited into the correct bank account as designated by OTA.

29.1.21 The LPT Processor shall reconcile all cash and check payments received from all sources to daily bank deposits.

Credit/Debit Card and ACH Processing 29.2

29.2.1 The LPT Processor shall be responsible for all aspects of credit/debit card and ACH processing.

29.2.2 The LPT Processor shall utilize the OTA credit/debit card and ACH service providers and employ methods and practices that provide OTA with the lowest possible credit/debit card and ACH fees. OTA will pay credit/debit card and ACH processing fees directly to the processors.

29.2.3 The LPT Processor shall accept payments via the following credit/debit cards, at a minimum: Visa, MasterCard, American Express and Discover.

29.2.4 The LPT Processor shall establish and maintain an interface with the credit/debit card/ACH processors.

29.2.5 The LPT Processor shall resolve credit/debit card and ACH transaction processing issues with the processors.

Page 86 of 111

29.2.6 The LPT Processor shall monitor and immediately report any transaction processing interruptions to OTA.

29.2.7 The LPT Processor shall reconcile LPT System credit/debit card transactions to information provided by the credit/debit card processor and the bank.

29.2.8 The LPT Processor shall ensure that the credit/debit card processor deposits all credit/debit card and ACH payments directly into appropriate bank accounts via electronic transfer.

29.2.9 The LPT Processor shall comply with the security and reporting standards of the credit/debit card issuer and processor.

29.2.10 The LPT Processor shall work with the credit/debit card processor in the review and resolution of customer credit/debit card chargebacks.

29.2.11 The LPT System shall flag payments that are in the chargeback review process and indicate resolution of the review in the account.

29.2.12 The LPT Processor shall make appropriate account adjustments in response to payment chargebacks.

29.2.13 The LPT Processor shall only store and transmit encrypted credit/debit card numbers and shall ensure security over credit/debit card information in compliance with the most current PCI standards.

29.2.14 The LPT Processor shall adhere to all requirements of the credit/debit card processor, the bank and PCI.

29.2.15 The LPT Processor shall review industry standards for enhancements and updates to the credit/debit card and ACH processing platform, at least annually, to ensure that the processing methods and systems remain current with the latest technology, security, and processing rules. The LPT Processor shall provide OTA with the results of such reviews.

29.2.16 In the event of an authorization decline from the processors for reasons other than a lost or stolen credit/debit card, the LPT Processor shall make a configurable number of authorization requests over a configurable period of time.

29.2.17 The LPT Processor shall ensure that all credit/debit card and ACH charges have been posted properly to customer accounts, transmitted to credit/debit card processor for payment, and that payments are received from the processor.

29.2.18 The LPT Processor shall reconcile all credit/debit card transactions with requests sent to the credit/debit card processor and with receipt of funds transferred by the processor.

29.2.19 The LPT Processor shall process all credit/debit card and ACH transactions on a daily basis.

Page 87 of 111

29.2.20 The LPT System shall track and record all activity related to credit/debit card and ACH payments, payment attempts, reversals and refunds in a customer's account within the LPT System in a sortable and searchable fashion.

29.2.21 The LPT System shall have a configurable limit to the number of customer initiated credit/debit card payments within a configurable period of time.

Cash and Checks Processing 29.3

29.3.1 The LPT Processor shall establish and implement procedures to accept and process all cash and checks received via mail.

29.3.2 The LPT Processor shall establish and implement procedures to accept and process payments received by PIKEPASS for LPT payments.

29.3.3 The LPT Processor shall establish and utilize electronic check processing.

29.3.4 The LPT Processor shall post all cash and checks received to the customer's account and process them for payment by the bank.

29.3.5 The LPT Processor shall provide an armored courier service for the transfer of funds to the designated bank.

29.3.6 The LPT Processor shall properly safeguard all cash and checks at all times and shall maintain records of the chain of custody of all funds.

29.3.7 The LPT System shall reverse any checks that are not honored, record them in the account and assess the appropriate non-sufficient funds (NSF) fee.

29.3.8 The LPT Processor shall establish and implement a process for including NSF check amounts due and related fees on invoices and violation notices.

29.3.9 The LPT System shall track the number of NSF checks received by an individual customer and have the ability to reject check payments by that customer after a configurable number of NSF checks have been received in a configurable period of time.

29.3.10 The LPT Processor shall account for and reconcile each payment received by payment type, by payment source, by CSR or payment processor, on a daily basis.

29.3.11 The LPT Processor shall utilize and support Positive Pay Processing for all refund checks issued. This includes the generation and issuance of Positive Pay files to the bank and the monitoring and handling of all related issues and exceptions.

29.3.12 The LPT Processor shall advise OTA of any issues related to Positive Pay on a daily basis.

Page 88 of 111

Refunds 29.4

29.4.1 The LPT Processor shall develop and implement OTA-approved Policies and Procedures to evaluate refund requests and process refunds for approved requests, including for eligible customer overpayments and error corrections. The methodology for refunds shall be finalized during design.

29.4.2 The LPT Processor shall designate and identify staff with the authority to process refunds.

29.4.3 The LPT Processor shall document all refunds in the LPT System customer account.

29.4.4 The LPT System shall track and report on refund activity on a monthly basis. This shall include refund information related to refund requests, issued refunds, refund method, accounts, dates, times, customer name and address data, approval level, name or employee ID number of individual processing and approving the refund, pending refunds, and the reason for approval or denial of the refund request.

29.4.5 The LPT Processor shall handle refunds that are returned by the post office as undeliverable in accordance with applicable Oklahoma State escheatment laws. The LPT Processor shall gather and package all data as directed by OTA.

29.4.6 The LPT Processor shall maintain PCI compliance regarding all credit/debit card refunds.

30 Cash Payment Network

Since OTA is removing the option to pay cash at certain locations on the roadway, OTA requires the LPT Processor to introduce a Cash Payment Network (CPN) at convenient merchant locations for patrons to pay invoices and violations using cash or other payment methods that may be accepted by the CPN. The sections below outline the requirements for the CPN.

General Cash Payment Location Requirements 30.1

30.1.1 The LPT Processor shall provide a Cash Payment Network (CPN) to accept customer funds at merchant locations.

30.1.2 The LPT Processor shall ensure the CPN provider is licensed to operate as a money services business in Oklahoma and all states in which the CPN is offering the OTA LPT program payments.

30.1.3 The LPT Processor shall guarantee to OTA all funds for all transactions processed at participating CPN locations.

30.1.4 The LPT Processor shall be responsible for all hardware, software and telecommunications costs incurred by the LPT Processor and its provider(s) associated with the provision of CPN transaction services.

Page 89 of 111

30.1.5 The CPN interface shall not degrade the LPT System’s performance, reliability, or availability.

30.1.6 The LPT Processor shall document measures being taken to ensure secure transfer of information between the CPN and the LPT Processor and its adherence to PCI compliance requirements.

30.1.7 The LPT Processor shall provide at least 48 hours advanced notice to OTA when the CPN is planned to be unavailable to OTA customers for more than 60 minutes.

30.1.8 The LPT Processor shall provide OTA with immediate notification anytime the CPN becomes unavailable to OTA customers for unplanned periods of longer than 60 minutes.

30.1.9 The LPT Processor shall ensure proper notification is displayed at the point of sale describing the CPN outage whenever the CPN is unavailable to OTA customers.

30.1.10 All payment processing requirements of this Scope of Work apply to payments made via the CPN.

CPN Payments 30.2

30.2.1 The LPT Processor shall implement a CPN that accommodates invoice and violation payment activities at each participating merchant location.

30.2.2 The CPN shall provide the ability for customers to view their outstanding amount due at no cost.

30.2.3 The CPN shall provide for configurable minimum and maximum payment amounts.

30.2.4 The CPN shall require either a scanned document barcode or two data entries for customer access validation as approved by OTA during design.

30.2.5 If the customer enters or scans a paid or escalated invoice barcode, the CPN shall retrieve and display the most recent total outstanding amount due on the account and allow the customer to make a payment to the account.

CPN Transaction Fees 30.3

30.3.1 CPN transaction fees, if any, shall be prominently displayed at the point of sale and available to the customer prior to completing the transaction.

30.3.2 CPN transaction fees charged to customers shall be approved by OTA.

30.3.3 CPN transaction fees shall be posted on the LPT/CPN webpage and printed on all transaction receipts.

Page 90 of 111

CPN Receipts 30.4

30.4.1 The CPN shall generate, OTA approved, printed receipts for all payments and shall advise customers to retain the receipt for their records as proof of payment.

30.4.2 The CPN shall ensure all receipts include complete transaction information, which may include any or all of the following (to be finalized during design):

• A CPN Reference ID number that uniquely identifies the payment and is searchable in the LPT System

• Type of document (invoice or violation) and document ID for which the payment was initiated

• Account number to which the payment was made • Total amount paid, with a breakdown of any fees • Amount due before payment • Amount due on the account, if any, after payment • Date and local time of the payment • Merchant location identifier • Name and contact details of the merchant • LPT Processor phone number and website address • Configurable message lines, for text to be provided and updated by OTA as

frequently as once per month

LPT and CPN Interface 30.5

30.5.1 The LPT Processor shall develop an interface to the CPN that implements all data exchanges necessary to meet the requirements contained herein.

30.5.2 The CPN System shall provide customers with the same up-to-date account balance information that would be available via the LPT Website or by calling the LPT Processor.

30.5.3 When a CPN transaction is complete at a merchant location, the LPT System shall immediately reflect the payment and update any remaining amount due on the account.

CPN Merchant Locations 30.6

30.6.1 The LPT Processor shall require all publicly located CPN merchant locations to accept cash. Locations may also accept other forms of payment (credit/debit card, check).

30.6.2 Each merchant location proposed for participation in the CPN by the LPT Processor shall require OTA approval prior to rollout or marketing of that location for OTA payments.

30.6.3 The LPT Processor shall ensure that CPN is available at merchant locations within a mutually agreed to area surrounding OTA tolling facilities.

Page 91 of 111

30.6.4 The LPT Processor shall provide OTA with a plan detailing the identification, recruitment, sign-on, training, and rollout of CPN merchant locations.

30.6.5 CPN services may be performed by point of sale (POS), kiosk, or other systems that shall be pre-approved by OTA.

30.6.6 The LPT Processor shall work with OTA to design a customer-friendly, intuitive user interface, with the final design requiring OTA approval prior to rollout.

30.6.7 The CPN user interface shall display a response to customer data requests in near real-time.

30.6.8 The LPT Processor shall monitor the quality of merchant services and discontinue a merchant location if it is determined that standards are not met or at the request of OTA (within one business day of the request).

CPN Merchant Locator 30.7

30.7.1 The LPT Processor shall develop and maintain a publicly available webpage for locating participating merchants that offer LPT CPN services (the Merchant Locator).

30.7.2 The LPT Processor’s CPN Merchant Locator shall provide a mobile-friendly website.

30.7.3 The LPT Processor shall ensure merchants that are no longer participating or do not meet requirements for the CPN are removed from the Merchant Locator within 1 business day of the removal of functionality, determination of failure to meet standards, or OTA request.

30.7.4 The LPT Processor’s CPN Merchant Locator shall allow users to retrieve a list of a configurable number of the CPN merchant locations closest to an address or Zip Code input by the user.

30.7.5 The LPT Processor’s CPN Merchant Locator shall list the CPN locations returned by the search—with street address, hours of operation, and phone number—and display them on a map view to the user.

30.7.6 The LPT Processor’s CPN Merchant Locator shall include the option to display a static map view of all participating CPN locations, without entering any search criteria.

30.7.7 The CPN Merchant Locator shall be available through the LPT Processor’s customer website.

CPN Reports 30.8

30.8.1 The LPT Processor shall provide daily, monthly and annual detailed CPN transaction reporting to include the following details for every transaction completed in the reporting period:

Page 92 of 111

Payment type (invoice or violation, based on input account/document ID) 30.8.1.1

Payment date and time 30.8.1.2

Account number 30.8.1.3

Invoice/violation number 30.8.1.4

Payment amount 30.8.1.5

Transaction fee amount 30.8.1.6

Merchant location ID 30.8.1.7

Merchant zip code 30.8.1.8

30.8.2 The LPT Processor shall provide daily, monthly, and annual CPN reporting to include the following summary information for all transactions completed in the reporting period:

Number of payments by type 30.8.2.1

Total payment amount by payment type 30.8.2.2

Total fees by payment type 30.8.2.3

Total payments by merchant location ID 30.8.2.4

Total payments by merchant location zip code 30.8.2.5

Total payments by merchant location county 30.8.2.6

30.8.3 The LPT Processor shall provide a monthly report with CPN system availability by location.

CPN Customer Service Requirements 30.9

30.9.1 The CPN and the LPT Processor shall clearly define and communicate to customers the appropriate point of contact for customer service related to CPN locations and transactions, in accordance with OTA-approved Policies and Procedures.

30.9.2 The LPT Processor shall train its staff to answer customer questions regarding CPN locations, procedures for using the CPN, and CPN usage and payment history.

30.9.3 The System shall flag financial transactions that occur at a CPN so that LPT Processor staff can identify them as such for research and customer service purposes.

30.9.4 The LPT Processor shall ensure each merchant location prominently displays a phone number for help with using the CPN.

Page 93 of 111

30.9.5 The LPT Processor shall provide Policies and Procedures for researching and addressing CPN customer complaints and this shall be provided to and approved by OTA prior to CPN rollout.

30.9.6 The LPT Processor shall ensure that a customer call center is available to address customer issues regarding the CPN. OTA strongly prefers the call center be available 24/7, however at a minimum, the CPN call center shall be available during the same hours that the LPT Processor call center is available.

31 Financial Responsibilities

General Financial Responsibilities Requirements 31.1

31.1.1 The LPT Processor shall establish and perform all financial functions necessary for the LPT operation, including accepting and processing payments, interfacing with banking institutions and credit/debit card and ACH processors, managing bank transactions and all reconciliations, and implementing audits and internal control procedures.

31.1.2 The LPT System shall have the ability to identify, segregate and accumulate revenue and accounts receivable between locations and cost centers as determined by OTA.

31.1.3 The LPT System shall provide an audit trail for each financial transaction.

31.1.4 The LPT Processor shall use proper cut-off procedures for daily, monthly, and year-end close.

31.1.5 The LPT Processor shall follow OTA’s daily, monthly, and year-end closing schedule and produce timely reports to allow OTA to meet its schedule.

31.1.6 The LPT System shall identify and report on transactions at various stages of their escalation process (e.g., outstanding violations and invoices).

31.1.7 The LPT System shall make a configurable bad debt calculation to each stage of the escalation process. This debt calculation shall include a configurable threshold for the amount outstanding.

31.1.8 The LPT System shall report on and track all write-offs.

Financial Reconciliation 31.2

31.2.1 The LPT Processor shall reconcile all financial activity on a daily and monthly basis.

31.2.2 The LPT Processor shall provide the results of all reconciliations including reconciliation spreadsheets and reports on resolution of variances to OTA in a timely manner.

31.2.3 The LPT Processor shall provide any documentation needed to support reconciliations upon OTA request.

Page 94 of 111

31.2.4 The LPT Processor shall resolve all variances through adjustments, reversals or research.

31.2.5 The LPT System shall allow users to record results of research, including comments and scanned documents or images, and associate the record with the variance.

31.2.6 As part of the report on resolution of variances, the LPT Processor shall provide a list of action items with a schedule for items that require extended research, system fixes, or other extended time periods for resolution.

31.2.7 The LPT System shall support the reconciliation processes. At a minimum, the LPT System shall do the following:

Exception identification 31.2.7.1

Automated reconciliation procedures 31.2.7.2

Drill down from summary level to the transaction or activity level 31.2.7.3

31.2.8 The LPT System shall provide automated reconciliations for all transactions.

31.2.9 The LPT Processor shall reconcile all payments received by the LPT System using automated system processes. These reconciliations shall include:

All reconciliations required in the payment processing section 31.2.9.1

Separate reconciliations of all types of fees, penalties and miscellaneous 31.2.9.2charges

Reconciliations by payment location, payment method, and fee types 31.2.9.3

Identification and resolution of all variances 31.2.9.4

31.2.10 The LPT Processor shall reconcile with banks and processors for cash, check, electronic funds transfers, ACH, credit/debit cards and any other form of payment regularly accepted using automated system processes. These reconciliations shall include:

Separate reconciliations for each bank account and processor 31.2.10.1

Reconciliation to LPT Processor reports 31.2.10.2

Identification and resolution of all variances 31.2.10.3

Page 95 of 111

32 Auditing

General Audit Requirements 32.1

32.1.1 The LPT Processor shall audit internal financial records and operations to ensure that it processes financial transactions accurately and in accordance with approved Policies and Procedures.

32.1.2 The LPT Processor shall hire a major independent certified public accounting firm to perform a Service Organization Control (SOC 1) Type 2 audit annually in accordance with Statement on Standards for Attestation Engagement No.16 (SSAE 16) and provide such report to OTA. This review shall include the effectiveness of operational controls related to software, procedures, data security, processing integrity, confidentiality, and privacy. The costs for such audits shall be borne by the LPT Processor.

32.1.3 The LPT Processor shall facilitate access to any material, system, or personnel that OTA or its authorized representatives require for auditing or examination of the LPT Processor’s activities. Such facilitation shall include LPT Processor staff time and effort working with OTA or its authorized representatives.

32.1.4 The LPT Processor shall develop and submit a remediation plan and remediation schedule to OTA for approval and shall implement all audit recommendations on a timely basis as approved by OTA.

Internal Controls 32.2

32.2.1 The LPT Processor shall establish and follow internal control procedures to ensure the safeguarding and proper accounting of OTA funds and related records at all times.

32.2.2 Internal controls shall be based on an industry standard such as the 2013 guidance from the Committee of Sponsoring Organizations of the Treadway Commission (COSO), “Internal Control – Integrated Framework”, or other appropriate standard.

32.2.3 The LPT Processor shall ensure that physical access to money, data, other assets, and documents is adequately safeguarded.

32.2.4 The LPT Processor shall detect and prevent revenue loss, errors, omissions, irregularities, and improper actions as well as identify revenue loss, errors, omissions, irregularities, and improper actions after they have occurred. Any occurrence shall be immediately reported to OTA.

32.2.5 The LPT Processors shall ensure that all financial activity is properly processed and accurately recorded.

32.2.6 The LPT Processor shall have controls and procedures in place to ensure that all processing is complete and accurate, including:

Page 96 of 111

Sanity checks 32.2.6.1

Acknowledgement files 32.2.6.2

Prevention of duplicate transactions 32.2.6.3

Reconciliations 32.2.6.4

Quality Assurance & Quality Control 32.2.6.5

32.2.7 The LPT Processor shall use exception reporting and sanity checks to detect and list unusual or invalid transactions, adjustments, charges and deviations from proper reconciliation with various components of the financial system.

32.2.8 The LPT Processor shall appropriately segregate duties for various transactions, including handling of cash and checks.

32.2.9 The LPT Processor shall conduct training that details the responsibilities of each employee with regard to internal controls, theft, fraud, embezzlement, fiscal misconduct, and violation of established policies.

32.2.10 The LPT Processor shall use computer system restrictions with varying levels of access control and restrictions on the type of transactions that may be performed by users.

32.2.11 The LPT Processor’s procedures shall require supporting information to verify the propriety and validity of transactions.

32.2.12 The LPT Processor shall ensure that approval authority is commensurate with the nature and significance of the transactions.

32.2.13 The LPT Processor shall remain current with and obey all federal and state applicable laws and regulations and any applicable financial or banking regulations and/or requirements.

33 Reporting

General Reporting Requirements 33.1

33.1.1 Through the LPT System, the LPT Processor shall provide all reports necessary to support the functions outlined in this document.

33.1.2 LPT System reports shall contain near real time data except as approved by OTA during system design.

33.1.3 The LPT System shall allow multiple simultaneous users to generate reports.

33.1.4 The LPT System shall provide all pre-defined reports and ad hoc report/query capabilities without interfering with the normal operations of the LPT System.

Page 97 of 111

33.1.5 The LPT System shall allow users to browse, apply selection criteria, and run reports on demand through a clearly displayed and user-friendly graphical user interface (GUI).

33.1.6 All authorized users, including OTA staff and its representatives, shall have direct access and be able to generate system reports without the need for intervention of LPT Processor staff.

33.1.7 The LPT System shall offer a robust reporting module that allows users to select date/time ranges, activity type, payment status, and other applicable selection criteria to be determined during the design phase.

33.1.8 The LPT System shall allow users to sort data in reports.

33.1.9 LPT System reports shall include sub-totals, totals and grand totals as appropriate.

33.1.10 The LPT System shall automatically generate reports at pre-determined configurable intervals or when criteria meet pre-determined configurable thresholds.

33.1.11 The LPT System shall allow authorized users to configure reports to be automatically generated on a scheduled basis for a predefined time period.

33.1.12 The LPT System shall support configurable automated distribution of reports via email.

33.1.13 The LPT System shall save all reports generated to a shared archive as configured by report or at the user’s discretion.

33.1.14 The LPT System shall allow authorized users to retrieve archived reports through the reports GUI.

33.1.15 The LPT System shall show reports on screen and allow users to print or to export a report to industry standard formats including Excel, Access, Adobe, PDF, CSV and HTML.

33.1.16 Wherever possible, exported reports shall be formatted to facilitate viewing in the destination format. For example, reports exported to Excel or CSV shall not have header/footer information repeated on multiple pages.

33.1.17 All reports shall contain a standard report header and/or footer that shall include:

ID of the user executing the report 33.1.17.1

Date/time the report was executed 33.1.17.2

Name of the report 33.1.17.3

Page number in the format “Page X of Y” 33.1.17.4

Selection criteria used to generate the report 33.1.17.5

Page 98 of 111

OTA logo or other such identifier (for formats that support this) 33.1.17.6

33.1.18 All reports shall be available to execute for standard user selectable timeframes including:

Hourly 33.1.18.1

Daily 33.1.18.2

Weekly 33.1.18.3

Monthly 33.1.18.4

Quarterly 33.1.18.5

Yearly 33.1.18.6

33.1.19 The LPT System shall allow users to perform business analysis using drill down, graphing, pivoting and cross-tabulation.

33.1.20 The LPT System reports database shall contain customer service operations data from the IVR system, website, CSR phone system, Cash Payment Network, and other tools used to provide customer service.

33.1.21 The detailed contents and layout of all system and manual reports and report selection screens shall be developed by LPT Processor and approved by OTA during the design phase.

Ad Hoc Reports 33.2

33.2.1 The LPT Processor shall allow for the generation of ad hoc reports through a user-friendly graphical interface.

33.2.2 The LPT System shall allow users to run ad hoc queries and generate reports.

33.2.3 The LPT System shall allow users to store ad hoc reports in a common directory for future access.

33.2.4 The LPT System shall allow authorized users to retrieve archived reports through the reports GUI.

33.2.5 The LPT System shall have run-time control limits to manage large queries, print jobs and downloads to prevent interference with normal operations.

33.2.6 The LPT System shall provide pop-up warnings to users when requested queries may be large and/or require time to compile.

33.2.7 The LPT System shall allow users to preview ad hoc query results and reports before downloading or printing.

Page 99 of 111

Research Screens 33.3

33.3.1 The LPT System shall provide screens that facilitate searching, filtering, and viewing data available in the LPT System reports database.

33.3.2 The LPT System may limit the number of results returned where not doing so may impact CSC operations; however, there shall be a notification to the user whenever the data returned has been limited.

33.3.3 The LPT System shall provide the ability to do research in areas including:

Transactions 33.3.3.1

Payments 33.3.3.2

Exceptions 33.3.3.3

Accounts 33.3.3.4

System alerts and system events 33.3.3.5

Data transfer logs 33.3.3.6

User tracking logs 33.3.3.7

Image Review 33.3.3.8

IVR and Call Center activity 33.3.3.9

Cash Payment Network activity 33.3.3.10

33.3.4 LPT System research screens shall allow authorized users to query the database using single or multiple parameters on any relevant field. For example, for a query of transactions, available fields might include transaction date/time, OCR confidence value, posting date, invoice date, due date, Host transaction number, license plate number, license plate jurisdiction, and transaction status.

33.3.5 The LPT System shall display a list of query results that includes high-level information relevant to that query, such as time, transaction number, and type. Details about this summary information shall be determined during the design phase.

33.3.6 The LPT System shall allow the user to select any result from the query results list and view more detailed information and/or link to another relevant screen, such as the related account screen.

Specific Report Requirements 33.4

33.4.1 At a minimum, the LPT System shall provide the reports included in this section; however, this is not all-inclusive and shall not relieve the LPT Processor from meeting

Page 100 of 111

reporting requirements specifically mentioned or implied in other parts of this Scope of Services.

33.4.2 The LPT Processor shall work with OTA to finalize reports during the design phase.

33.4.3 The LPT System shall provide performance monitoring reports as required to monitor and audit compliance with the Performance Standards detailed in Appendix F.

33.4.4 The LPT System performance monitoring reports shall cover all required Performance Standards, comparing actual performance for each standard with the standard itself.

33.4.5 The LPT System shall provide reports on customer service operations that cover all aspects of customer service on a daily basis and over selected date ranges, at both a summary and detail level.

33.4.6 At a minimum, the LPT System shall provide customer service reports on the following:

Customer contacts by contact method, by time period, by type of 33.4.6.1correspondence, and by topic (e.g., payment, dispute, PIKEPASS conversion)

Incoming mail volumes by time period and by type 33.4.6.2

33.4.7 The LPT System shall provide reports on all aspects of the IVR and call center activity to allow users to determine the effectiveness and efficiency of the IVR system and customer service representatives over the phone.

33.4.8 The LPT System shall provide IVR and call center activity reports, at both a detail and a summary level, for various periods including hourly, daily, weekly, monthly and annual.

33.4.9 The LPT System shall provide IVR and call center activity reports that allow users to analyze and compare call center data for similar periods (e.g., the most recent Monday compared to prior Monday and average Monday over the past quarter, year, etc.).

33.4.10 LPT System call center reports shall provide call center data including:

Call Origin 33.4.10.1

Call Volumes 33.4.10.2

Call Reason Codes (reason for call) 33.4.10.3

Call Wait Times 33.4.10.4

Average Talk Time 33.4.10.5

Average Wrap Time 33.4.10.6

Page 101 of 111

Total Average Talk and Wrap Time 33.4.10.7

Abandoned Calls 33.4.10.8

Abandoned Call Rate 33.4.10.9

Service Levels 33.4.10.10

Use of the IVR Menus 33.4.10.11

Transfers 33.4.10.12

33.4.11 The LPT System shall provide website reports on all aspects of website to allow users to determine the effectiveness and usability of the website.

33.4.12 The LPT System shall provide website reports, at both a detail and a summary level, on a daily basis, monthly basis, and over a user-selected date range.

33.4.13 LPT System website reports shall provide data including:

Number of website page hits 33.4.13.1

Use of the website page links 33.4.13.2

Activity conducted on the web 33.4.13.3

Length of time spent on the website 33.4.13.4

Payments 33.4.13.5

Use of links to OTA website 33.4.13.6

Use of links to CPN locator 33.4.13.7

33.4.14 The LPT System shall provide image review reports that give detail and summary information for daily, monthly, and user-specified date ranges.

33.4.15 The LPT System image review reports shall provide data including:

Number of images received from OTA for review 33.4.15.1

Disposition of all images received 33.4.15.2

Number of images reviewed 33.4.15.3

Number of readable images 33.4.15.4

Number of unreadable images by reject code 33.4.15.5

Page 102 of 111

Number of images re-reviewed 33.4.15.6

Number of images reviewed from Watch List 33.4.15.7

33.4.16 The LPT System shall provide reports on LPT accounts with detail and summary information as follows:

Account status, including past due statuses 33.4.16.1

Newly established accounts 33.4.16.2

Accounts with frequent toll activity 33.4.16.3

Payment method 33.4.16.4

Payments made 33.4.16.5

Invoice delivery method 33.4.16.6

Account balance 33.4.16.7

Invoice Escalation status including invoice aging, violations, collections 33.4.16.8and Stop Flag status (all by date)

Flag for accounts with past CPN activity 33.4.16.9

33.4.17 The LPT System shall provide reports of invoices issued by specific variables including date, amount due, violation status, payment type, zip code, and mail suppression status.

33.4.18 The LPT System shall provide reports on violations that show, at a detail and a summary level, the current status of all violations.

33.4.19 The LPT System shall provide reports on its interfaces with other systems such as the Host, banks, payment processors, CPN, DMVs and the collection agency.

33.4.20 LPT System interface reports shall provide detail and summary information by date and by interface to:

Verify the timely, complete, and accurate transmission of information 33.4.20.1

Allow reconciliation between reports on counts and amounts from the 33.4.20.2other entity on data sent versus data received

Identify any corrupt or missing information 33.4.20.3

Allow for research of variances identified 33.4.20.4

Page 103 of 111

33.4.21 The LPT System shall provide reports on LPT transaction processing and disposition that show the current status of all transactions at both a detail and a summary level, by any of the following criteria:

Transaction date 33.4.21.1

Transmission date 33.4.21.2

OCR confidence value 33.4.21.3

Posting date 33.4.21.4

Invoice date 33.4.21.5

Past due status 33.4.21.6

Violation status 33.4.21.7

33.4.22 The LPT System transaction reports shall allow examination by:

Interim statuses such as image review, ROV look up, queued for invoicing 33.4.22.1

Most recent reconciliation code returned to the Host 33.4.22.2

Stage in the invoicing process 33.4.22.3

Violation status, including registration stop flag status 33.4.22.4

Final statuses such as posted, rejected, paid, turned to collection or 33.4.22.5dismissed

33.4.23 The LPT System shall provide reports tracking all invoices, escalations and violation notices sent to customers.

33.4.24 LPT System escalation reports shall allow users to track the current status of all invoices and violation notices by transaction date (range) and date of invoice/notice issuance. At a minimum, these reports shall allow examination of:

Payment details 33.4.24.1

Adjustments 33.4.24.2

Write offs 33.4.24.3

Tolls 33.4.24.4

Fees 33.4.24.5

Vehicle registration stop flags or other escalated collection efforts 33.4.24.6

Page 104 of 111

Average payment amounts and length of time until payment 33.4.24.7

Aging reports 33.4.24.8

33.4.25 The LPT System shall provide an invoice summary report showing a current snapshot of all transactions that have been invoiced for a selectable period. This report shall be broken down by invoice escalation status at the time the report is run. The report shall include:

The number of transactions invoiced for the period 33.4.25.1

The number of transactions by escalation status 33.4.25.2

The toll and fee amounts charged by escalation status 33.4.25.3

The toll and fee amounts paid by escalation status 33.4.25.4

The toll and fee amounts dismissed/written off, by reason 33.4.25.5

The toll and fee amounts due by escalation status 33.4.25.6

33.4.26 The LPT System shall provide reports on all rejected transactions. At a minimum, these reports shall show at a detail and a summary level the reasons for rejected transactions by transaction date. The reports shall allow analysis of:

Rejects by reason 33.4.26.1

Drill downs into reject reasons 33.4.26.2

DMV lookup failures 33.4.26.3

Trends and variances 33.4.26.4

Rejects by jurisdiction 33.4.26.5

Repeated attempts at a process such as DMV lookup 33.4.26.6

Rejects by stage of transaction processing 33.4.26.7

33.4.27 The LPT System shall provide all the reports required to audit, reconcile, monitor and record the financial activity of the LPT operation.

33.4.28 The LPT System shall provide reports on all payments received.

33.4.29 At a minimum, the LPT System payment reports shall provide detail and summary information by payment date for all payments.

33.4.30 The LPT System payment reports shall allow users to examine payments by:

Page 105 of 111

Payment methods 33.4.30.1

Payment processor or bank 33.4.30.2

Payment location 33.4.30.3

CSR clerk 33.4.30.4

Successful versus failed payment attempts 33.4.30.5

Reasons for payment failures 33.4.30.6

Chargebacks 33.4.30.7

Variances between expected totals and actuals 33.4.30.8

33.4.31 The LPT System shall provide reports on transaction counts and revenue. At a minimum, these reports shall provide detail and summary information by date and by location.

33.4.32 The LPT System transaction count and revenue reports shall have month and year end roll ups. These revenue reports shall allow users to examine revenue by:

Vehicle class 33.4.32.1

Collected revenue versus accounts receivable 33.4.32.2

Adjustments 33.4.32.3

Trend and variance analysis including same month-prior year comparison 33.4.32.4

PIKEPASS V-Tolls 33.4.32.5

33.4.33 The LPT System shall provide reports on refunds that provide detail and summary information on refunds.

33.4.34 The LPT System refund reports shall allow users to examine refunds by:

Request date 33.4.34.1

Refund status 33.4.34.2

Amount 33.4.34.3

Refund reason 33.4.34.4

Refunds issued 33.4.34.5

Refunds sent to OTA for approval 33.4.34.6

Page 106 of 111

33.4.35 The LPT System shall provide reports necessary for system administration that give detail and summary information on user activity, system configurations and system issues.

33.4.36 The LPT System admin reports shall allow users to examine:

User lists 33.4.36.1

User permissions 33.4.36.2

User activity logs (identifies user, screens viewed, printouts, reports 33.4.36.3created, and date and time of use)

Automated reports, schedule, and distribution 33.4.36.4

System configuration history 33.4.36.5

Alerts or alarms 33.4.36.6

Maintenance history 33.4.36.7

33.4.37 The LPT Processor shall provide OTA with Monthly Status Reports that include the following:

Number of invoices issued by delivery method 33.4.37.1

Number of images reviewed 33.4.37.2

Number and percent of rejected images by reason 33.4.37.3

Number and percentages of invoices escalated by past due status / 33.4.37.4escalation level, including violation (1st notice and 2nd notice), registration stop flag and collections

Payments by type; Visa, MasterCard, AMEX, Discover, ACH, cash/check 33.4.37.5

Payments by source; mail, web, LPT CSR call, OTA CSR call, IVR, OTA 33.4.37.6walk-in centers, collection agency, DMV, CPN

Total number of customer calls, number of calls entered into a CSR queue, 33.4.37.7number of calls answered, and number of calls abandoned

Number of calls resolved via the IVR by reason 33.4.37.8

Average call wait time, average call talk time, average wrap time, average 33.4.37.9call handle time (talk and wrap time)

Average number of daily and monthly calls, average daily calls answered, 33.4.37.10average daily calls abandoned (provided in total and by day of the week)

Page 107 of 111

Average web access by hour and by day of the week 33.4.37.11

Disputes by source 33.4.37.12

Refunds by source 33.4.37.13

Payments by source 33.4.37.14

Progress for the prior month for all outstanding action items 33.4.37.15

All potential delays and problems in addressing outstanding issues or 33.4.37.16software updates

New action items and issues 33.4.37.17

Progress on activities requiring coordination with OTA or other external 33.4.37.18parties

Deliverables scheduled for submittal in the next reporting period 33.4.37.19

Monthly Performance Reports, including comparison to the Performance 33.4.37.20Standards

30-day look-ahead on activities to clear action items 33.4.37.21

Other items as deemed noteworthy by OTA or the LPT Processor 33.4.37.22

34 Performance Standards

To promote the consistent, timely, accurate, and reliable operation of the LPT operation, OTA has identified key requirements for which specific Performance Standards have been developed for on-going monitoring and evaluation. These Performance Standards, the adjustment threshold and the adjustment percentages or adjustment amounts (reductions for non-compliance) are listed in Appendix F. Each of the Performance Standards is associated with one or more of the price categories listed in the Pricing Matrix.

General Performance Standard Requirements 34.1

OTA will directly link the LPT Processor’s compensation with the LPT Processor’s compliance with the Performance Standards. 34.1.1 The LPT Processor shall fully meet or exceed all of the requirements detailed in this

document and the Performance Standards.

34.1.2 In accordance with the requirements of this section, the LPT Processor shall establish and implement an ongoing process to monitor, measure, calculate, and report compliance with the Performance Standards.

Page 108 of 111

34.1.3 The LPT Processor shall submit the format, content and methodology of all performance reporting to OTA for review and approval during the design phase, in accordance with the approved Project Schedule.

34.1.4 For each of the Performance Standards, the LPT Processor shall measure actual performance for each standard based on the required frequency.

34.1.5 The LPT Processor shall report compliance with each Performance Standard on a monthly basis in conjunction with submitting the invoice payment request to OTA.

34.1.6 If the LPT Processor fails to meet any of the Performance Standards, the LPT Processor shall report the deficiencies, calculate the adjustments, and reduce the LPT Processor’s related pricing categories on the following month’s invoice payment request to OTA.

34.1.7 Non-compliance with a Performance Standard and/or the assessment of related invoice adjustments shall not release the LPT Processor from its obligation to complete all required work.

34.1.8 The LPT Processor shall make available to OTA all performance related documentation and reporting, and this will be subject to audit at the discretion of OTA. Actual performance results calculated by the LPT Processor that differ from audited results may be subject to further retroactive adjustment of amounts paid or payable by OTA.

34.1.9 The LPT Processor shall perform all calculations for determining compliance or non-compliance with a Performance Standard to three decimal places.

34.1.10 The following describes the process and methodology that the LPT Processor shall use in determining compliance/non-compliance with Performance Standards, related invoice adjustments and reporting.

The determination of compliance or non-compliance with each 34.1.10.1Performance Standard and any resulting invoice adjustment shall be made individually and separately for each standard. For example, if one Performance Standard states that “Paper invoices shall be mailed within 3 calendar days of the invoice date” with an Adjustment Threshold of 98% and another Performance Standard states that “Paper invoices shall be mailed within 5 calendar days of the statement date” with an Adjustment Threshold of 100%; the LPT Processor may be non-compliant with one, both, or neither of the two standards. Therefore, depending on compliance, the LPT Processor may be assessed an invoice adjusted for one, both or neither standard.

The determination of compliance or non-compliance shall be based on the 34.1.10.2items processed during the specified period (calendar month, day, etc.). For example, if during the month of June, 1,000 images are processed by

Page 109 of 111

the LPT Processor; compliance shall be determined based on those specific 1,000 images.

Appendix F lists an adjustment threshold for each Performance Standard. 34.1.10.3If the measured performance of each item meets or exceeds the thresholds, then no adjustment to the invoice for that period is made. However, if the actual performance does not at least meet the threshold on any item, an automatic price adjustment will be triggered and OTA will reduce the invoice amount for the related pricing categories accordingly.

Appendix F specifies two methods for calculating the price adjustment 34.1.10.4depending on the specific Performance Standard. Under one method, the LPT Processor shall adjust the invoice by a specific dollar amount for each instance of non-compliance with the Performance Standard. The other method, as described below, requires the LPT Processor to adjust the invoice based on a percentage of the defined pricing categories for the month.

The percentage method employs tiered adjustment percentages. Invoice 34.1.10.5payment deductions shall escalate as actual performance results fall further below the required standard. The adjustment percentage shall determine the amount of payment reduction and shall depend on how far the actual performance falls below the adjustment threshold. If the actual performance is below the adjustment threshold by 5% (absolute) or less, the first adjustment percentage shall be used. If the actual performance is more than 5% but less than 15% below the threshold, a higher percentage is used. Finally, if the performance falls to more than 15% below the threshold, an even higher adjustment percentage is used.

Each Performance Standard is associated with one or more of the Pricing 34.1.10.6Categories and is subject to adjustment for non-compliance with Performance Standards.

More than one pricing category may be related to a Performance Standard. 34.1.10.7If more than one pricing category is listed for a specific Performance Standard, activity for all the categories shall be combined to calculate compliance with the Performance Standard, with any adjustments for non-compliance then being applied to each of the specified pricing categories.

The calculated invoice reduction amount for standards that are non-34.1.10.8compliant shall be increased by 50% if the same standard was found to be non-compliant in any of the 3 months immediately prior to the month for which the adjustment is being made. The 50% increase in the invoice reduction shall only be applied to the month being invoiced and not to prior months’ invoices.

Waiver of the calculated invoice adjustments described above will be at the discretion of OTA.

Page 110 of 111

Example Performance Standard Adjustment (Percentage Method) 34.2

Following is an example calculation of an invoice adjustment for non-compliance with a specific Performance Standard that shall be followed by the LPT Processor. The example is based on hypothetical values.

Performance Standard

Price Category: Invoices Mailed (paper) Performance Standard: “All paper invoices shall be mailed with 4 business days of the end

of the invoice cycle.”

Adjustment Threshold: 100% Adjustment Percentage (0-5%): 2% Adjustment Percentage (> 5% but < 15%): 4% Adjustment Percentage (>15%): 6%

Actual Performance

# of invoices mailed during the month: 10,000 # of invoices mailed within standard: 9,600 Actual Performance (in compliance with standard): 96%

Determination of Compliance & Adjustment Percentage

Since the actual performance for the month (96%) was below the adjustment threshold (100%), the LPT Processor is non-compliant with the Performance Standard for the month. As a result, an invoice price adjustment shall be made to the appropriate price category for the specific standard. Adjustment threshold: 100% Actual performance: 96% Deviation from threshold: 4% Since the deviation from the threshold of 4% falls into the range of 0% to 5%, the Adjustment Percentage of 2% is used to calculate the invoice adjustment.

Calculation of Price Adjustment

Invoice amount for pricing category related to this Standard (prior to adjustment): Pricing Category: Invoices Mailed Pricing Units: # of Invoices Mailed # of Invoices Mailed (for example): 10,000

Page 111 of 111

Unit Price (for example purposes): $0.25 per Invoice Mailed Invoice Amount for Price Category (prior to adjustment): $2,500 for month Invoice Adjustment for Non-Compliance with Performance Standard: Invoice Amount for Price Category (prior to adjustment): $2,500 for month Adjustment Percentage (0-5%): 2% Invoice Adjustment: $50 ($2,500 x 2%)

Amount payable for this pricing category for the month

$2,500 less $50 = $2,450 (assuming all other Performance Standards related to this pricing category were found to be in compliance with the Performance Standards). The LPT Processor shall perform the above calculation, with appropriate adjustments, for each of the Performance Standards that did not meet the adjustment threshold.

Appendix A -‐ OTA LPT Requirements Traceability Matrix

Appendix A -‐ Page 1 of 87

Yes No Yes No Yes No1 I. General Requirements2 1 Project Overview3 1.1 Summary of Scope4 1.1.1 The LPT Processor shall provide a comprehensive, fully tested and

integrated, “turn-‐key” solution that shall meet or exceed all requirements herein and shall be responsible for all activities related to establishment, implementation and on-‐going operation of the OTA LPT operation as described in this document.

5 1.1.2 The LPT Processor shall work cooperatively with OTA for such things as PIKEPASS integration testing and ongoing operations.

6 1.2 Quality Assurance & Quality Control7 1.2.1 The LPT Processor shall establish, implement and maintain a Quality

Assurance (QA) and Quality Control (QC) program throughout all phases of the Contract.

8 1.2.2 The LPT Processor shall establish and implement procedures to identify, define, track and report to OTA all items that could adversely impact the success of the Project and/or any areas that may impact customers or their perception of the Project and/or OTA. These items include, without limitation, call center performance, timely and accurate issuance of statements and invoices, transaction processing, image review, all aspects of customer service (including call quality and customer satisfaction), meeting milestone dates, reliability and accuracy of data, and the integrity of reports and financial Transactions.

9 1.2.3 The LPT Processor shall ensure that all QA/QC requirements are met by all of its Subcontractors and vendors.

10 1.2.4 The LPT Processor shall prevent, detect, and correct deviations from any requirement, including by Subcontractors, and report such items to OTA.

11 1.2.5 The LPT Processor’s QA/QC program shall address all staffing, equipment, methods, procedures, activities, and schedule requirements relating to QA/QC activities.

12 1.2.6 The LPT Processor’s QA/QC program shall ensure the accuracy and timeliness of the issuance of statements, invoices and general correspondence.

13 1.2.7 The LPT Processor’s QA/QC program shall continually evaluate LPT operations for accuracy, completeness, and efficiency.

14 1.2.8 The LPT Processor shall establish procedures to ensure that all requirements of the Contract are performed completely, accurately and in a timely manner and correct any area of performance that is below standard.

Remarks Proposal Reference(s)

Fully Supported by Existing Sys./Ops

If not supported by Existing System, will requirement be

met via new system development/operation?

Row # Requirement Number

Requirement

Non-System/Non-Operational Requirement:

Will the requirement be met by the Proposer?



Yes No Yes No Yes No






Requirement



15 1.2.9 The LPT Processor’s QA/QC program shall include reasonableness checks that evaluate accuracy and efficiency such as analyses of abnormal deviations in quantity, volume, dollar amounts, elapsed time, and staff hours.

16 1.2.10 The LPT Processor shall implement changes and/or corrective action upon error identification during the QA/QC processes.

17 1.2.11 1.2.11 The LPT Processor shall review a random sample of invoices from every batch, automatically generated by the system, for accuracy and quality. The following are checked: -‐ Issued date;-‐ Due date;-‐ Customer address;-‐ License plate number; and-‐ Toll amounts.

18 1.3 Customer Satisfaction Surveys19 1.3.1 The LPT Processor shall establish a process to perform customer

satisfaction surveys via the IVR and mail. 20 1.3.2 1.3.2 The LPT Processor shall work with OTA to finalize the content and

questions included in the customer satisfaction surveys.21 1.3.3 1.3.3 The LPT Processor shall implement the customer satisfaction

surveys as directed by OTA, as frequently as annually.22 1.3.4 1.3.4 The LPT Processor shall report the results of customer satisfaction

surveys to OTA within one week of the conclusion of a survey period.23 1.3.5 1.3.5 The LPT Processor shall not include the time customers spend

interacting with the customer satisfaction survey in its call time statistics.

24 1.4 Existing OTA Contracts25 1.4.1 The LPT Processor shall coordinate its Work with the services provided by

OTA’s other contractors. The pre-‐existing contracts are as follows: 26 1.4.1.1 Credit Card Processor – currently TransFund27 1.4.1.2 Banking Services – currently Bank of Oklahoma28 1.4.1.3 Collections Services – currently Kansas Counselors, Inc.29 1.4.1.4 DMV ROV Look-‐up – currently American Traffic Solutions (optional)30 2 Project Management31 2.1 General Project Management Requirements32 2.1.1 The LPT Processor shall manage the planning and execution of all aspects

of the requirements in this document. 33 2.1.2 The LPT Processor shall provide project management throughout the

term of the contract.









Requirement



34 2.1.3 The LPT Processor shall coordinate its activities with OTA and other agencies, as required.

35 2.1.4 The LPT Processor shall execute the Project in accordance with all required Plans.

36 2.1.5 The LPT Processor shall deliver monthly and quarterly status reports providing review and analysis of the LPT operation.

37 2.1.6 The LPT Processor shall schedule and meet with OTA Management on a monthly basis to present and discuss monthly and quarterly status reports.

38 2.1.7 The LPT Processor shall provide a schedule of services to OTA, as needed, for deployment of new Software, LPT System enhancements, bug fixes, hardware upgrades, and any functionality required for security and LPT System vulnerability mitigation.

39 3 Staffing40 3.1 Staffing Plans -‐ Team Organization41 3.1.1 The LPT Processor shall develop a detailed Staffing Plan for OTA review

and approval in accordance with the Project Schedule. 42 3.1.2 The Staffing Plan shall address staffing during the Design and

Development Phase and during the LPT Operations Phase. 43 3.1.3 The Staffing Plan shall include, but not be limited to, the following: 44 3.1.3.1 A description of the LPT Processor’s Project team organization,

reporting relationships, key project personnel and team member contact information.

45 3.1.3.2 The physical location of all staff. 46 3.1.3.3 A detailed Project organization chart that is a graphical representation

of the LPT Processor’s staff hierarchy, including any Subcontractors, and indicates functional areas of responsibility as well as the number of staff by position.

47 3.1.3.4 Performance objectives for each work position and how the LPT Processor shall continuously monitor personnel performance against these objectives.

48 3.1.3.5 Corrective actions for dealing with any unsatisfactory performance. 49 3.1.3.6 A description of the LPT Processor’s Policies and Procedures regarding

the selection of qualified staff, the performance of background checks, the assignment of staff to handle sensitive information and compliance with applicable employment regulations.

50 3.1.3.7 A description of all Subcontractor relationships and responsibilities. 51 4 Documentation Requirements52 4.1 General Documentation Requirements









Requirement



53 4.1.1 The LPT Processor shall maintain all documentation related to the LPT design, development and operation as defined in this scope of work.

54 4.1.2 The LPT Processor shall maintain a soft copy library of current versions of all Project documents in a secure location with web access for all approved members of the OTA Project team.

55 4.1.3 If changes occur in any aspect of the Project that alters operations, the LPT Processor shall update relevant documentation within one month of that change, unless a specific alternative update schedule is approved by OTA.

56 4.1.4 The LPT Processor shall back up all soft copy library files at least daily.57 4.1.5 The LPT Processor shall maintain all documentation in formats found in

the Microsoft Office suite unless otherwise specified by OTA.58 4.1.6 The LPT Processor shall make all documentation available to OTA in

electronic copy format. Electronic versions shall be in the original format in which the document was created (e.g., Microsoft Word/Excel).

59 4.1.7 The LPT Processor shall ensure each document produced contains a title sheet, table of contents, list of illustrations (if applicable), revision log, and list of reference drawings (if applicable).

60 4.1.8 With the exception of the original equipment manufacturer standard documentation (e.g., manuals, catalogs), the LPT Processor shall ensure all documents are formatted to be printed double-‐sided on 8.5" by 11" sheets and may include 11" by 17" “engineering fold” inserts.

61 4.1.9 The LPT Processor shall ensure the left-‐hand margin of the sheets in documents is adequate to ensure binding without encumbering the reading of the material.

62 4.1.10 The LPT Processor shall ensure all drawings, graphs, plans, charts, and illustrations are produced with computer aided drafting software or other software approved by OTA.

63 4.2 Deliverable Management 64 4.2.1 The LPT Processor shall submit all deliverables and work products to OTA

for review, comment and approval. OTA reserves the right to reject documents prior to detailed review due to the document’s failure to meet the purpose and intent of the deliverable. In the event a deliverable is rejected, OTA will notify the LPT Processor of the basis for rejection in writing. Rejection of a deliverable shall constitute a delay caused by the LPT Processor if a completed version of the document is not approved by the document final version approval date in the approved Project Schedule.

65 4.3 Document Reviews









Requirement



66 4.3.1 The LPT Processor shall submit documents for OTA’s review, comment, and approval in accordance with the approved Project Schedule. The schedule shall allow for a minimum of two review/revision cycle iterations, with a 10-‐Business Day OTA review period for each cycle.

67 4.3.2 OTA may require additional review time if the LPT Processor submits multiple, simultaneous or overlapping submittals or deliverables in excess of 100 pages.

68 4.3.3 The LPT Processor shall submit an empty, multi-‐column comments matrix with each document. OTA will enter its comments into the matrix and the LPT Processor shall track the status of all comments as well as comment responses and resolution for every comment in the matrix.

69 4.3.4 The LPT Processor shall update the relevant documents to address comments submitted by OTA in sufficient time to maintain the approved Project Schedule.

70 4.4 Submittal Approval71 4.4.1 OTA’s approval of documents shall not relieve or limit the LPT Processor’s

responsibility to provide systems and services in full compliance with the Contract.

72 4.4.2 If and when OTA submits comments, the LPT Processor shall resubmit the documentation and deliverables until such time as OTA accepts the document. Any time required for re-‐submittal or review of re-‐submittals shall not be an OTA-‐Caused Delay.

73 4.4.3 Deviations from the requirements set forth in this Scope of Services that may be contained within LPT Processor submitted documents, even though the document may be approved by OTA, shall not have the effect of modifying any requirement set forth in the Contract unless such deviations are explicitly disclosed as deviations and OTA expressly acknowledges and approves the deviations. Only formal requests to OTA, from the LPT Processor, for waivers or specification changes that are formally approved by OTA shall modify the requirements set forth in the Contract.

74 5 Project Communications 75 5.1 Project Scope76 5.1.1 All decisions or directives relating to Project scope, schedule, design,

procedures, Business Rules, or policy must be in writing and approved by OTA, in order to be incorporated into the official Contract Documents.

77 5.2 Meetings









Requirement



78 5.2.1 The LPT Processor shall develop meeting agendas for all meetings called by the LPT Processor or requested by OTA.

79 5.2.2 The LPT Processor shall distribute meeting agendas at least 24 hours in advance of all meetings for OTA approval.

80 5.2.3 The LPT Processor shall record notes of all meetings and distribute copies of the draft notes to attendees within 3 Business Days of the meeting for review and comment. At a minimum, the LPT Processor shall include the following in all meeting notes:

81 5.2.3.1 A complete list of attendees, whether present or on website/phone82 5.2.3.2 Descriptions of issues discussed83 5.2.3.3 Decision items, if any, shall be summarized at the beginning of all

meeting note documents84 5.2.3.4 Direction given85 5.2.3.5 Open issues86 5.2.3.6 Specific action items, including the responsible individual and

estimated completion dates 87 5.3 Status Meetings – Design and Development 88 5.3.1 The LPT Processor shall schedule status meetings, at least monthly, with

designated OTA staff throughout the Design and Development phase. Commencing within the first 30 days after Notice To Proceed (NTP) and continuing until Go-‐Live the LPT Processor shall schedule and conduct monthly status meetings with OTA to review the status of the Design and Development effort.

89 5.3.2 Commencing within the first 30 days after issuance of NTP and continuing to System Acceptance, the LPT Processor shall submit a Monthly Progress Report.

90 5.3.3 The LPT Processor shall submit Design & Development -‐ Monthly Progress Reports by the 7th Business Day of each month for the preceding month.

91 5.3.4 The LPT Processor shall include the following in all Monthly Progress Reports:

92 5.3.4.1 Progress for the prior month for all Project activities.93 5.3.4.2 Actual start and actual finish dates of work, percentage complete, and

days remaining for work-‐in-‐progress.94 5.3.4.3 All potential delays and problems, if any; actions the LPT Processor is

taking to address the delays or problems, and their estimated effect on the Project Schedule and overall Project completion.

95 5.3.4.4 Electronic copies of the updated Project Schedule. If there are any changes to the schedule from the previous Monthly Progress Report the changes shall be highlighted.









Requirement



96 5.3.4.5 Progress on activities requiring coordination with third parties.97 5.3.4.6 Deliverables scheduled for submittal in the next reporting period.98 5.3.4.7 30-‐day look-‐ahead report on all activities scheduled.99 5.4 Status Meetings – Operations100 5.4.1 Commencing within the first 30 days after Go-‐Live and continuing

through the end of the Contract, the LPT Processor shall schedule and conduct monthly status meetings with OTA to inform OTA of the performance of the system and operations, any problems noted and solutions.

101 5.4.2 Monthly status meetings shall include discussion about customer service call quality, customer satisfaction, performance standards and any related issues.

102 5.4.3 The LPT Processor shall submit Operations -‐ Monthly Status Report (see Requirement 33.4.37) by the 7th Business Day of each month for the preceding month.

103 6 Project Schedule104 6.1 General Project Schedule Requirements105 6.1.1 Within 15 business days after NTP, the LPT Processor shall submit a

detailed critical path Project Schedule that supports a Go-‐Live date, currently set for January 4, 2017. This date is dependent on the completion of construction of the ramps at Elm/Peoria. Construction is tentatively schedule to be completed for the first ramp at the end of June 2016 and in mid-‐October 2016 for the second ramp.

106 6.1.2 The Project Schedule shall identify all tasks to be accomplished and related dates from System Design to System & Operational Acceptance.

107 6.1.3 The Project Schedule shall include deliverable and approval dates for all documents that will be submitted for OTA review and approval.

108 6.1.4 Once the Project Schedule is approved by OTA, the approved version shall be considered the Baseline Schedule and shall not change without explicit written consent from OTA.

109 6.1.5 The Project Schedule shall be updated as needed to reflect the current state of the schedule, in addition to showing the Baseline Schedule dates for all tasks.

110 6.1.6 The Project Schedule shall include all detailed steps that are required to accomplish scheduled Go-‐Live, including Design, Development and Testing, with related dates.

111 6.1.7 The LPT Processor shall create a Project Schedule that provides a fully functional LPT operation meeting all requirements in this Scope of Services by the Go-‐Live date.









Requirement



112 6.1.8 Go-‐Live shall be achieved when all of the following have been completed:

113 6.1.8.1 OTA receipt and approval of the all pre Go-‐Live test reports.114 6.1.8.2 OTA receipt and approval of confirmation that the LPT System and

software escrow deposit contains the current version of all software and materials.

115 6.1.8.3 OTA receipt and approval of all Project deliverables.116 6.1.8.4 Successful Go-‐Live in accordance with the OTA approved Go-‐Live plan.

117 6.1.9 The LPT Processor shall include time for submittal, review and approval of all Project deliverables in the Project Schedule.

118 6.1.10 Throughout the Term, the LPT Processor shall monitor, and update the Project Schedule whenever changes to the LPT System or operations of a material nature occur, or as directed by OTA.

119 6.1.11 The LPT Processor shall submit the Project Schedule in Microsoft Project and Adobe PDF formats.

120 6.2 Schedule Delays121 6.2.1 The LPT Processor shall identify and promptly report to OTA all Project

Schedule and progress delays during the execution of the Project. 122 6.2.2 In the event of any Project Schedule delay, the LPT Processor shall take

appropriate action to develop a recovery schedule. 123 6.2.3 The LPT Processor shall submit a recovery schedule immediately

following the identification of a Project Schedule delay. 124 6.2.4 Recovery schedules shall not release the LPT Processor from liability for a

delayed schedule. 125 6.3 Schedule Revisions126 6.3.1 The LPT Processor shall submit proposed changes to the Project Schedule

along with the reason for the proposed changes for OTA approval as it becomes necessary to modify the Project Schedule.

127 6.3.2 Until OTA approves in writing any schedule revision, all Project Schedule submittals shall be tracked against the previously approved Baseline Schedule.

128 6.3.3 Approved schedule changes shall not release the LPT Processor from the original requirements and Contract Deadlines unless explicitly agreed to in writing by OTA.

129 6.3.4 The LPT Processor shall create a revised schedule, based on approval of a proposed schedule change, and it shall be used as the basis for the subsequent monthly Project Schedule updates and reports.

130 7 Data Retention and Destruction131 7.1 General Data Retention and Destruction Requirements









Requirement



132 7.1.1 The LPT Operator shall be responsible for the retention, archiving and destruction of data related to the LPT program.

133 7.1.2 The LPT Operator shall not destroy any data or records without specific approval of OTA, except as necessary in maintaining compliance with PCI standards.

134 7.1.3 All archival parameters shall be configurable for each type of data.135 7.2 Specific Data Retention and Destruction Requirements136 7.2.1 All account specific data and records related to open accounts and/or

accounts with unpaid amounts shall be available to authorized users via the LPT System for at least 3 years and shall be archived and retrievable throughout the term of the Contract, including any extensions.

137 7.2.2 All account specific data and records not covered in Requirement 7.2.1 shall be available to authorized users via the LPT System for 2 years, archived and retrievable for an additional 3 years, and then destroyed.

138 7.2.3 All non-‐account specific System data and records shall be maintained in the LPT System for 2 years, archived and retrievable for an additional 3 years, and then destroyed.

139 7.2.4 All non-‐account specific hard copy documents shall be maintained at the LPT processing location for 2 years, archived and retrievable for an additional 3 years, and then destroyed.

140 7.2.5 Hard copies of all scanned documents shall be retained for 3 months after being scanned, and then destroyed.

141 7.2.6 The LPT Processor shall perform all data and document destruction within 3 months after the required retention timeframe is reached.

142 7.2.7 The LPT System shall be capable of restoring archived data on a temporary basis for research and query purposes.

143 8 Succession 144 8.1 Succession Plan145 8.1.1 Within 365 days of NTP, the LPT Processor shall prepare and submit a

Succession Plan for OTA review and approval. 146 8.1.2 The Succession Plan shall detail a method for the orderly transfer of LPT

operations including knowledge, data, manuals, documents, assets, call routing, licensing and business relationships from the LPT Processor to the successor service provider (“Successor”) or OTA, should the Contract terminate for any reason.

147 8.1.3 The Succession Plan, when implemented, shall ensure no interruption of LPT operations.

148 8.1.4 At the specific written direction of OTA, the LPT Processor shall implement, perform and carry out all activities as described in the OTA approved Succession Plan.









Requirement



149 8.1.5 The Succession Plan shall include an overview and sequential steps detailing the transfer of each LPT operational area to the Successor or OTA.

150 8.1.6 The Succession Plan shall include, at a minimum, sections covering operational shut downs and the transfer and/or replacement of:

151 8.1.6.1 Physical assets, including a current list of assets and their owners152 8.1.6.2 Staffing and organization, including training 153 8.1.6.3 Product usage and Software licenses, including a current list of licenses

(name, purpose, identifier, contact information, license details)

154 8.1.6.4 Leasing agreements, including a current list of leases (name, purpose, terms, dates, contact information)

155 8.1.6.5 Service contracts, including a current list of contracts (name, purpose, terms, dates, contact information)

156 8.1.6.6 Customer information (for example, current and historical data records, Transaction processing histories, images, scanned and hard copy documents, open call center cases, applications, forms, correspondence)

157 8.1.6.7 Customer notification outreach158 8.1.6.8 Call routing159 8.1.6.9 Financial ledgers and other financial information160 8.1.6.10 LPT System configuration histories161 8.1.6.11 Archived data162 8.1.6.12 Correspondence templates (editable electronic and printed copies)163 8.1.6.13 Invoice/violation notice templates (editable electronic and printed

copies)164 8.1.6.14 Current Policies and Procedures documentation 165 8.1.6.15 Other information or knowledge necessary for succession or as

otherwise reasonably requested by OTA166 8.1.7 The LPT Processor shall update the approved Succession Plan to account

for any subsequent changes in policy or operations within 30 days of the change. The updated Succession Plan shall be submitted to OTA for review and approval.

167 8.2 Succession Procedures168 8.2.1 In the event that Notice of Succession is given to the LPT Processor by

OTA, the LPT Processor shall designate a succession manager to be a single point of contact for all succession-‐related issues. The succession manager shall convene regular meetings with relevant staff and with OTA or its designated representatives, at which succession-‐related issues can be tracked, discussed, and resolved.









Requirement



169 8.2.2 Upon Notice of Succession, the LPT Processor shall immediately coordinate formal reviews of all succession activities as detailed in the Succession Plan.

170 8.2.3 Upon Notice of Succession, the LPT Processor shall develop, submit to OTA for review, finalize, and subsequently adhere to a succession transition schedule that accommodates the needs of the Successor and/or OTA, relative to smoothly transitioning to a new LPT Processor and/or OTA.

171 8.2.4 Upon Notice of Succession, the LPT Processor shall provide staff time to work with OTA and/or the Successor to establish database extract procedures acceptable to the OTA and/or the Successor, for the purpose of migrating the LPT System data.

172 8.2.5 Upon Notice of Succession, the LPT Processor shall provide staff time to work with OTA and/or the Successor to establish mapping conventions acceptable to the OTA and/or the Successor, for the purpose of migrating data to the new LPT Processor.

173 8.2.6 In the event of a succession, the LPT Processor shall make its existing management staff available for in-‐person interviews with OTA and/or the Successor staff.

174 8.2.7 The LPT Processor shall provide in-‐person training of Successor and/or OTA staff with experienced LPT Processor staff on an “as needed” basis upon request of OTA for a period from Notice of Succession until the end of the Term.

175 8.2.8 In the event of a succession, the LPT Processor shall ensure the accustomed quantity and quality of staff, supervisors and management are maintained throughout the entire period during which LPT operations is being transitioned to the Successor or OTA.

176 II. Design, Development and Testing 177 9 System Development 178 9.1 System Design and Development Plan (SDDP)179 9.1.1 The LPT Processor shall provide for OTA’s review and approval a SDDP

that defines the LPT Processor’s approach to design and development of the LPT System.

180 9.1.2 The SDDP shall include specific details of system development, including definition, design, programming, submittal and acceptance of software design deliverables, documentation, and software quality assurance.

181 9.1.3 The SDDP shall include the software life-‐cycle methodology that will be utilized as well as the technical approach, problem reporting and tracking process, software configuration and change management, and regression testing and revision control.









Requirement



182 9.1.4 The SDDP shall include plans for design, development, testing and implementation of interfaces between the LPT System and external entities, as described in Appendix E.

183 9.1.5 The SDDP shall be used for future LPT System modification beyond minor bug fixes. At a minimum, for post-‐acceptance changes, the process shall include a business case and written acceptance of this document by OTA.

184 9.1.6 The SDDP shall provide a description of the structure of the software development team that will be assigned to the Project and how personnel will be assigned to the various system development disciplines, including software development, system engineers, test engineers, software test personnel, configuration management staff, documentation specialists, project management staff and software maintenance personnel.

185 9.2 Requirements Review Workshops186 9.2.1 The LPT Processor shall facilitate workshops with OTA and other parties

designated by OTA to refine the requirements, covering at least customer communications, finance, accounting, reporting, website, and operations.

187 9.2.2 During these workshops, the LPT Processor shall clarify system requirements and Business Rules to ensure a full understanding of the intent of the system functions and Business Rules. The LPT Processor shall discuss how it shall meet requirements through operational procedures, the LPT Processor’s existing system functionality, system configuration or enhancements to its LPT System.

188 9.2.3 The LPT Processor shall participate in all meetings with OTA and other parties designated by OTA to determine the requirements for the various interfaces, as directed by OTA.

189 9.3 Requirements Traceability Matrix (RTM)190 9.3.1 The LPT Processor shall update the Requirements Traceability Matrix in

Appendix D with the results of the workshops and provide it to OTA for approval.

191 9.3.2 The LPT Processor shall continuously maintain and update the RTM throughout the life of the Project and shall include only OTA-‐directed requirements or OTA-‐approved changes that affect the design or functionality of Project hardware or software thereto.

192 9.3.3 The RTM shall show the origin of requirements, any changes to requirements, and the source of approval for those changes.









Requirement



193 9.3.4 The RTM shall be used to verify compliance throughout the system design and development phase, testing and deployment, and into the Operations Phase.

194 9.3.5 The LPT Processor shall ensure the LPT System and all supporting activities and deliverables comply with the RTM throughout the entire life cycle of the Project.

195 9.3.6 The LPT Processor shall deliver an OTA-‐approved RTM in accordance with the approved Project Schedule.

196 10 Design 197 10.1 General Design Requirements198 10.1.1 The LPT Processor shall produce a Preliminary Design Document (PDD)

and a System Design Document (SDD) covering the applicable RTM items and the approved Business Rules.

199 10.2 Preliminary Design Document and Review200 10.2.1 The Preliminary Design Document (PDD) shall contain detailed

information on LPT system design and technical approach and shall include, but not be limited to, the following:

201 10.2.1.1 General system design202 10.2.1.2 RTM203 10.2.1.3 System software specifications and design204 10.2.1.4 System hardware specifications and design with cut sheets205 10.2.1.5 System and software of the phone system206 10.2.1.6 Physical and logical network overview207 10.2.2 The LPT Processor shall provide system and subsystem block diagrams

and data flow diagrams, and demonstrate compliance with system requirements.

208 10.2.3 The LPT Processor shall submit hardware concept drawings during this review.

209 10.2.4 The LPT Processor shall submit the PDD three weeks in advance of the scheduled PDR workshop. The PDD will be reviewed by OTA and comments provided to the LPT Processor.

210 10.2.5 The PDR workshop will be held to review the design documentation, discuss OTA comments and provide an in-‐depth review of the system design and the design documentation.

211 10.2.6 The PDR workshop shall take place at OTA offices. The LPT Processor shall provide minutes/action items from the PDR and submit revised versions of the documentation for OTA review and approval. This process will be repeated until OTA determines that the PDD is acceptable.

212 10.3 System Design Document (SDD) and Review









Requirement



213 10.3.1 The SDD shall be an extension of the approved PDD documents and shall include detail such as block diagrams, hardware and software design, user interface and screen layouts, report formats, operational procedures, other pertinent design documentation including a list of equipment for each function along with a description of its role.

214 10.3.2 The SDD shall include, but not be limited to, the following:215 10.3.2.1 Scope of Project216 10.3.2.2 RTM217 10.3.2.3 Specification sheets for all equipment218 10.3.2.4 Full software manual set for all Commercial off the Shelf (COTS)

software as requested by OTA219 10.3.2.5 System sizing and design details220 10.3.2.6 Description of all third party software, including Operating Systems221 10.3.2.7 System, subsystem and module level descriptions 222 10.3.2.8 Description of interactions between modules223 10.3.2.9 Requirements for all peripheral device interfaces224 10.3.2.10 Examples (mockups) of all reports225 10.3.2.11 Description of system diagnostics, status monitoring and error

handling226 10.3.2.12 Description of redundancy and failover processes227 10.3.2.13 End to end transaction diagram228 10.3.2.14 Interface Control Documents (ICDs) for all external entities229 10.3.2.15 File and transaction message formats230 10.3.2.16 Design for user interfaces including graphical representation (screen

shots or mockups) of all menus and screens231 10.3.2.17 Database design and ERD/Data Dictionary232 10.3.2.18 Basic Data communications diagram233 10.3.2.19 Communications network logical design234 10.3.2.20 Communications network physical design235 10.3.3 The LPT Processor will submit a SDD for design approval that describes

the design specifications of all hardware, software and communications to be provided by the LPT Processor to meet the requirements of the Project.

236 10.3.4 The LPT Processor shall describe all hardware specifications, including appropriate diagrams and facility layouts, in the hardware design.

237 10.3.5 The LPT Processor shall illustrate the software design and architecture and include modules and/or process levels and procedures. The software design details shall include the code used and how it interacts with the underlying Operating System.









Requirement



238 10.3.6 The SDD will form the basis for the Detail Design Review (DDR) and will be submitted for review, comment and discussion, after which the design reviews will take place.

239 10.3.7 The DDR provides the final review of the SDD, as implemented in accordance with the approved PDR approach.

240 10.3.8 The SDD must be received from the LPT Processor no later than three weeks in advance of the scheduled DDR meeting to allow OTA to review the documents in detail prior to the meeting.

241 10.3.9 Upon completion of the design reviews, the SDD shall be revised and submitted to OTA for final review and approval.

242 10.3.10 Upon OTA’s approval of the SDD, the LPT Processor shall update the Project Schedule, if necessary, and the RTM to reflect any changes in requirements approved during the design process.

243 10.3.11 The LPT Processor shall provide minutes/action items from the DDR and submit revised versions of the documentation for OTA review and approval. This process will be repeated until OTA determines that the SDD is acceptable.

244 10.3.12 Within 30 days after successful completion of the System Acceptance Test, the LPT Processor shall submit the Final SDD, including all changes made during the software development, installation and testing phases.

245 10.3.13 The LPT Processor shall provide all hardcopy submittals in three-‐ring binders, accompanied by electronic (soft) copies.

246 10.3.14 The LPT Processor shall update and submit to the designate person at OTA, the Final SDD with any changes implemented during ongoing operations within 10 business days of the change.

247 11 Testing Requirements248 11.1 General Testing Requirements249 11.1.1 The LPT Processor shall conduct testing of the system to validate the LPT

System integrity, reliability, functionality, accuracy and compliance to the requirements of this RFP and demonstrate that the LPT System meets all of the approved requirements in the RTM.

250 11.1.2 OTA and its representatives shall have the option to witness or take part in, any or all testing, and the LPT Processor shall work with OTA to schedule tests so that OTA staff, representatives and partners may observe and/or participate in all formal testing.









Requirement



251 11.1.3 During the development of the system software, the LPT Processor’s test personnel shall conduct a comprehensive program of internal testing and walk-‐through sessions with OTA to ensure that the LPT System meets the functional specifications set forth in this RFP and that defects are detected and resolved or identified prior to formal demonstration testing witnessed by OTA.

252 11.1.4 The LPT Processor shall be responsible for all development and test personnel, equipment, facilities and expenses associated with all system testing.

253 11.1.5 The LPT Processor shall submit test plans, with test scripts, to OTA for review, comment and approval, at least 15 business days in advance of each test.

254 11.1.6 The LPT Processor shall incorporate comments and revisions received from OTA and update the Project Schedule, if necessary.

255 11.1.7 The LPT Processor shall obtain OTA approval of test plans and scripts prior to testing.

256 11.1.8 The LPT Processor shall accommodate ad hoc testing by OTA during formal testing.

257 11.1.9 The LPT Processor shall conduct all tests in accordance with the project schedule and the approved test plans and procedures.

258 11.1.10 Within 10 calendar days of the completion of each test, the LPT Processor shall deliver a test results report to OTA which shall include a listing of all defects (punch list) identified together with the severity level of each (severity levels will be determined in the Master Test Plan); a plan for resolving those defects; and a recommendation for retests (if appropriate).

259 11.1.11 The LPT Processor shall provide to OTA a report of all test results, notes, and observations.

260 11.1.12 The LPT Processor shall work together with OTA to indicate a priority level for each punch list item.

261 11.1.13 The LPT Processor shall correct and retest all punch list items including necessary regression.

262 11.1.14 The LPT Processor and OTA shall agree on a schedule for correcting and retesting punch list items.

263 11.1.15 When OTA deems that all punch list items have been resolved, the LPT Processor shall receive final approval of that test.

264 11.2 Master Test Plan (MTP)265 11.2.1 The LPT Processor shall provide a Master Test Plan describing all tests to

be performed from NTP through and including System & Operational Acceptance.









Requirement



266 11.2.2 The final set of tests to be conducted shall be finalized during the design phase; however, at a minimum, the LPT Processor shall include the following tests in the Master Test Plan:

267 Table 1 See Table 1: Testing Summary tab. 268 11.2.3 The MTP shall provide a description of each test, the standards for

developing individual test plans and the procedures for the formal testing. These standards shall address test procedure format, severity levels and acceptance criteria for each formal test phase. In addition, the MTP shall describe the entry criteria that must be met before each formal test can be started and the exit criteria that must be met before each test can be considered complete.

269 11.2.4 The MTP shall address testing approaches and schedule, performance criteria, data collection and sampling methods, testing conditions, testing locations, reporting of results, and procedures for tracking and retesting/regression testing for failed tests.

270 11.2.5 The MTP shall be submitted to OTA for review and approval according to the approved Project Schedule.

271 11.3 General Test Plan Requirements 272 11.3.1 The LPT Processor shall provide for OTA’s review and approval (prior to

test commencement) an individual test plan for each test listed in Table 1.

273 11.3.2 Each test plan shall include a description, scope, approach, required resources, schedule, including test items, all dependencies (including reliance on and readiness of third parties), test platform (including required equipment and location), features to be tested, test scripts and their expected results, entry and exit criteria including pass/fail criteria, a placeholder to record any defects noted during the test and a description of the ranking that will be used for classifying and recording any defects noted (e.g. critical, major, minor), definitions of a successful test, a place holder to record actual results and any risks requiring contingency planning.

274 11.3.3 The LPT Processor shall provide all test and support personnel, test equipment and test sites in accordance with the approved Master Test Plan. OTA will review and approve formal test plans and schedules proposed by the LPT Processor and will witness and determine the acceptability of the test results.

275 11.3.4 Test plans shall document workflows and business processes established during the design phase.









Requirement



276 11.3.5 Test plans shall clearly list requirements that the LPT Processor will not test at each respective stage and the reason for their exclusion. These excluded requirements shall be subject to OTA review and approval.

277 11.3.6 Test plans shall describe how data to be tested will be compiled, such as through use of data simulation software or other mutually agreed upon data sets to create necessary Transaction and payment data.

278 11.3.7 The LPT Processor shall update each version of the test plans to incorporate or respond to OTA comments on the previous version.

279 11.3.8 The Factory Acceptance Test plan shall be submitted for OTA approval no sooner than 15 business days after approval of the SDD.

280 11.4 Factory Acceptance Test (FAT)281 11.4.1 LPT Processor shall conduct the Factory Acceptance Test at the end of

the development phase in accordance with the approved Project Schedule.

282 11.4.2 The FAT shall take place at the LPT Processor’s development facility or other equivalent site in the continental United States.

283 11.4.3 The FAT shall be a test of the LPT System, using the same communications equipment, software, hardware, user interfaces and configurations as the LPT Processor will use in production.

284 11.4.4 The FAT shall follow a set of transactions and payments through various use cases that demonstrate the workflow through various sub-‐systems including LPT processing, image review, Interactive Voice Response (IVR) system, website, customer statements/invoices, and reports, etc.

285 11.4.5 The LPT Processor shall coordinate with OTA on how to obtain test Transaction and image file data.

286 11.4.6 The FAT shall utilize compiled Transaction and payment data to perform tests including, but not limited to, a full range of required reports, financial data flow and Transaction and payment reconciliation.

287 11.4.7 The LPT Processor shall obtain OTA approval of FAT results prior to Installation and Interface Testing.

288 11.5 Installation and Interface Test 289 11.5.1 The LPT Processor shall conduct the Installation and Interface Test after

the LPT System has been installed in the designated primary hosting site location.

290 11.5.2 The Installation and Interface Test shall thoroughly test all of the network communications and other physical systems, according to a plan to be approved by OTA.

291 11.5.3 To the extent possible, the LPT Processor shall acquire test files from external interface sources to allow for the widest possible tests of LPT System functionality.









Requirement



292 11.5.4 The LPT Processor shall cooperate with all testing required by third parties with external interfaces as directed by OTA.

293 11.5.5 The LPT Processor shall demonstrate the interface with the OTA Host to show that it can receive and process Transaction and image files, send results files back through the interface in the agreed-‐upon format, and show proper system logs of the send/receive cycle.

294 11.5.6 At a minimum, the LPT Processor shall include the following interfaces in the Installation and Interface Test:

295 11.5.6.1 Host/PIKEPASS 296 11.5.6.2 Credit/debit card processors297 11.5.6.3 Banks298 11.5.6.4 DMV/Third parties299 11.5.6.5 Mailhouse300 11.5.6.6 Collection Agency301 11.5.7 The LPT Processor shall obtain OTA approval of the Installation and

Interface Test results prior to Disaster Recovery testing and the Production Readiness Test.

302 11.6 Disaster Recovery Test303 11.6.1 During the Disaster Recovery Test, the LPT Processor shall exercise the

Disaster Recovery/Business Continuity Plan to the fullest extent possible, simulating various LPT System failures and challenges for LPT Processor staff.

304 11.6.2 The LPT Processor shall obtain OTA approval of Disaster Recovery Test results prior to Go-‐Live.

305 11.6.3 The LPT Processor shall conduct the Disaster Recovery Test during Production Readiness Testing.

306 11.6.4 The LPT Processor shall conduct Disaster Recovery Testing at least annually after Go-‐Live.

307 11.7 Production Readiness Test308 11.7.1 The PRT shall continue until the results are approved by OTA. The goal of

a successful PRT is to prove the LPT System and operations are ready for production and the decision to ‘Go-‐Live.’

309 11.7.2 Upon completion of construction of each ramp, the LPT Processor shall begin to receive and process transaction and image data from the Host to the LPT System for use in exercising the functionality and processes at the CSC.

310 11.7.3 The LPT Processor shall perform the Production Readiness Test using actual Host data from transactions created at the Elm-‐Peoria toll points until Go-‐Live.









Requirement



311 11.7.4 The LPT Processor shall provide documentation of the agreed-‐to system configuration as part of the Production Readiness Test Plan.

312 11.7.5 This Production Readiness Test shall include but not be limited to:313 11.7.5.1 Creating new accounts, issuing invoices, violations, payment

processing, handling disputes and managing accounts through the website, and IVR system

314 11.7.5.2 Invoice escalation including violations and collections315 11.7.5.3 Making adjustments in the LPT System to emulate all account and

financial functions, including transfer of responsibility, chargebacks, refunds, and NSF checks

316 11.7.5.4 Interfacing with OTA’s finance department and systems317 11.7.5.5 Providing special ad hoc queries, running daily and weekly reports, and

conducting research on possible issues318 11.7.5.6 Setting up test credit/debit cards and other mechanisms to simulate

payments319 11.7.5.7 Testing of LPT accounts and maintenance functions320 11.7.5.8 Call routing between the LPT Processor and PIKEPASS 321 11.7.6 The LPT Processor shall perform license plate lookup queries during the

Production Readiness Test.322 11.7.7 The LPT Processor shall coordinate with DMVs and any third party DMV

services to test the ROV lookup and license/registration hold interface. 323 11.7.8 The LPT Processor shall provide all necessary training and support in the

use of the PIKEPASS CSC resources and LPT System to all users prior to conducting the Production Readiness Test.

324 11.7.9 The LPT Processor shall provide remote access for OTA and its representatives to access the LPT System during the Production Readiness Test.

325 11.7.10 The LPT Processor shall track and document all anomalies, failures, and other issues noted by test participants and observers during this period.

326 11.7.11 The LPT Processor shall prepare and deliver a test report with all issues prioritized and corrective actions assigned on a weekly basis.

327 11.7.12 The LPT Processor shall work with OTA to determine and agree upon required retesting.

328 11.7.13 The LPT Processor shall continue testing data and recording, prioritizing, and working to correct issues identified until OTA approves a final set of Production Readiness Test results.

329 11.8 System & Operational Acceptance Test330 11.8.1 The System & Operational Acceptance Test shall begin immediately upon

Go-‐Live or as soon as all criteria for entry to this test have been met.









Requirement



331 11.8.2 The System & Operational Acceptance Test shall include but not be limited to:

332 11.8.2.1 Ensuring the accuracy, consistency and completeness of data recorded in the database and reflected in reports

333 11.8.2.2 Performance monitoring and ensuring that all requirements and Performance Standards are met or exceeded

334 11.8.2.3 Following Policies and Procedures, resulting in an efficiently functioning CSC that meets all requirements

335 11.8.3 The LPT Processor shall perform a detailed review of all financial reports, which shall determine that all transactions are accurately summarized, fully accounted for, and supported by detailed Transaction reports.

336 11.8.4 The LPT Processor shall create a punch list of defects and a report on Performance Standards early in the System & Operational Acceptance Test period to allow early fixes and testing without revenue impacts to the Project. Approval of the System & Operational Acceptance Test shall occur when the LPT Processor demonstrates that it meets all requirements in the SOAT Plan and achieves compliance with all required Performance Standards over 3 consecutive calendar months of CSC Operations.

337 12 Go-‐Live 338 12.1 General Go-‐Live Requirements339 12.1.1 The Go-‐Live period shall occur over a maximum of three days. 340 12.1.2 The LPT Processor shall have completed and obtained OTA approval for

all testing except System & Operational Acceptance.341 12.1.3 The LPT Processor shall provide a detailed Go-‐Live Plan covering the

three-‐day Go-‐Live period. 342 12.1.4 The Go-‐Live plan shall include an hour-‐by-‐hour schedule, a checklist of

tasks and tests occurring during Go-‐Live, the go/no-‐go decision point, and any other information necessary to ensure a smooth Go-‐Live.

343 12.1.5 The LPT Processor shall evaluate all aspects of its planned operations and ensure that all mechanisms are in place to manage those operations in accordance with all requirements prior to Go-‐Live.

344 12.1.6 The LPT Processor shall report on its evaluation to OTA, seek OTA’s approval for implementing any resulting recommendations, and document any such measures implemented.

345 III. License Plate Tolling Operational Requirements346 13 Technical Requirements347 13.1 System Requirements348 13.1 LPT System Data Center Requirements









Requirement



349 13.1.1 The LPT Processor shall provide both a Primary and a Disaster Recovery (DR) data center, with a minimum Tier 3 rating, to house the required infrastructure to process designated OTA LPT transactions and images. A Tier 3 data center is composed of multiple active power and cooling distribution paths, but only one path active, has redundant components, and is concurrently maintainable, providing 99.982% availability.

350 13.1.2 In both the Primary and DR data centers, the LPT Processor shall maintain and monitor the HVAC(s) system such that it provides the proper environmental conditions that are required for the LPT System.

351 13.1.3 The LPT Processor shall ensure the LPT System data center components are protected from power outages by the use of generators.

352 13.1.4 The LPT Processor shall ensure LPT System components are protected by a Power Distribution Unit (PDU) and an Uninterruptible Power Supply (UPS) capable of surge suppression and powering the LPT System during utility to generator transfers.

353 13.1.5 The LPT Processor shall monitor all PDUs and UPSs for health and loading.

354 13.1.6 The LPT Processor shall design, procure and configure a physical and logical Local Area Network (LAN) for the LPT System at the Primary and DR data centers using commercially available hardware.

355 13.1.7 The LAN topology shall be designed to eliminate single points of failure at network layers 1, 2, and 3. The design and equipment shall be subject to OTA review and approval.

356 13.1.8 The OTA LPT System shall exclusively use the LAN. No other systems housed in the LPT Processor’s data centers shall use the LAN provided to OTA.

357 13.1.9 In order to establish communication paths between the Host, LPT Account holders, third party interfaces, and data center to data center a Wide Area Network (WAN) connection shall be provided by the LPT Processor at both the Primary and Disaster Recovery data centers.

358 13.1.10 It is the LPT Processor’s responsibility to provide and configure all required equipment and cabling to accommodate the WAN link.

359 13.1.11 The LPT Processor shall coordinate with third party Internet Service Providers (ISP) to install the WAN link within each LPT System data center. The up front and recurring costs of the WAN link shall be the responsibility of the LPT Processor.

360 13.1.12 The LPT Processor’s WAN topology, bandwidth, and equipment shall be subject to OTA review and approval.

361 13.1.13 The LPT Processor shall ensure that no data is lost in the event of a data transmission failure.









Requirement



362 13.1.14 The LPT System data center components shall be housed in their own secured cabinet/rack. Only authorized and OTA approved personnel shall have access to the LPT System Facility rack.

363 13.2 LPT System Requirements364 13.2.1 The LPT Processor shall furnish an active-‐standby LPT System between its

Primary and DR Data Centers. The LPT System shall include all cabinets, enclosures, servers, storage systems, Keyboard, Video, and Monitor (KVM)s, cabling, and any ancillary equipment, as may be necessary to provide a complete and acceptable LPT System and shall be designed, sized and maintained to meet or exceed all operational and functional requirements and all Performance Standards in this RFP throughout the Term.

365 13.2.2 The LPT System shall be scalable to meet increased volumes.366 13.2.3 The LPT Processor shall provide an isolated LPT System, meaning it will

not share physical or logical system, network, or infrastructure components with other co-‐located clients. Two exceptions for sharing physical components are the data building and the data center utility power.

367 13.2.4 The LPT Processor shall provide hosts that contain adequate memory and processing capacity to meet all requirements.

368 13.2.5 The LPT System shall include hot swappable components and sub-‐systems wherever available.

369 13.3 LPT System Operating System and Software370 13.3.1 The operating system for the LPT System(s)/server(s) shall consist of a

Commercial Off the Shelf (COTS) multi-‐user, multitasking operating system.

371 13.3.2 The LPT Processor is responsible for obtaining all licenses as required and all necessary licenses will be obtained for all COTS operating system software used by the LPT System.

372 13.3.3 The LPT Processor will retain authorized copies (backups) for all software media to use for periodic system maintenance, upgrades, or restorations, as required.

373 13.3.4 The proposed operating system shall have warranty and COTS maintenance support services for the Term of the Contract.

374 13.3.5 If Microsoft Windows is selected, the LPT Processor shall utilize Microsoft Windows 7 or greater for desktops and Windows Server 2012 R2 or greater for servers.









Requirement



375 13.3.6 The operating system shall be a proven system and version release with a large installed base, used widely throughout the United States for enterprise-‐class operations and shall be compatible with relevant database and web-‐based development and operational tools, and shall not be a “Beta” or first release version.

376 13.3.7 The LPT Processor shall maintain the Operating System with necessary updates and security patches.

377 13.4 LPT System Dashboard378 13.4.1 The LPT System shall provide a dashboard screen that allows authorized

users to monitor the LPT System with drilldown capabilities. This shall include an overview of LPT operations including transaction volume by facility, call center activity, image review, ROV lookups, invoice/violation issuance and escalation, and number of accounts. Specific examples of detail include:

379 13.4.1.1 Call Center-‐ Total incoming calls -‐ Number of calls requesting a CSR-‐ Number of calls answered by a CSR-‐ Average wait time for CSR calls-‐ Average call handling time-‐ Maximum wait time for CSR calls-‐ Number & Percentage of CSR calls that exceed a specified wait time-‐ Abandoned call rate

380 13.4.1.2 Image Review-‐ Oldest transaction date currently being reviewed-‐ Percentage of images rejected -‐ Top 3 image reject reasons-‐ Number of image in queue

381 13.4.2 The dashboard shall allow drilldown capabilities for each of these areas so that users can view activity on an hourly, daily, weekly, monthly and annual basis. It shall also include comparisons to prior activity.

382 13.4.3 The dashboard shall provide a visual and graphical representation of the Transaction workflow and shall display data in real-‐time as well as historical roll-‐up.

383 13.4.4 The LPT Processor shall monitor the dashboard and also allow OTA to view the dashboard 24/7/365 on a real time basis. All information that is related to different locations shall be tracked individually as well as in total.









Requirement



384 13.4.5 End users shall have the ability to customize their own dashboards by changing column sort criteria, changing the order that columns of data are displayed and hiding columns.

385 13.4.6 The LPT System shall allow users to establish configurable thresholds for monitoring LPT System and operational performance.

386 13.4.7 The LPT System shall generate alerts when deviations from established thresholds occur.

387 13.5 Database Requirements388 13.5.1 The LPT System database shall incorporate redundancy in order to

minimize LPT System downtime.389 13.5.2 The LPT Processor shall design and configure the LPT System database to

minimize the possibility of data loss.390 13.5.3 The LPT Processor shall design and configure the LPT System database to

support future hardware and software upgrades. 391 13.5.4 The LPT Processor shall design the LPT System database to be compatible

with the operating system and application software.392 13.5.5 The LPT Processor shall design the LPT System database to support

redundant central processing system architectures. 393 13.5.6 The LPT Processor shall provide database software with warranty and

maintenance support services for the term of the contract.394 13.5.7 The LPT Processor shall keep the LPT System database software

current—that is, within one major release of the database manufacturer's current general production version.

395 13.5.8 If Microsoft SQL Server is selected, the LPT Processor shall utilize Microsoft SQL Server 2014 or greater for database software.

396 13.5.9 The LPT Processor shall provide database monitoring tools such that all aspects of the database are monitored, including but not limited to software capable of alerting appropriate staff to the presence of alarm conditions, capable of giving authorized users real time overviews, details, histories, and maintenance tools suitable for investigating and making adjustments to LPT System database performance, session-‐level activity, scheduled jobs, alert notification and configuration parameters.

397 13.5.10 The LPT Processor shall provide and maintain a reporting database or a data warehouse that replicates all the data from the LPT System database, in near real time, to be used for all user-‐generated reports, including those described in the reports section of this Scope of Services.

398 13.5.11 The LPT Processor shall configure the reporting database or data warehouse so as to optimize report generation including appropriate indexes and views to allow ad-‐hoc user generated queries.









Requirement



399 13.5.12 The LPT System database shall store certain fields in encrypted form (for example credit/debit card numbers), as determined with OTA during system design. It is the preference of OTA not to maintain social security and/or driver’s license numbers within the LPT System; however OTA understands that some information may be automatically returned by certain DMV sources. In the event that personal information is obtained, the LPT Processor shall ensure this data is fully protected in compliance with prudent personally identifiable information (PII) provisions.

400 13.5.13 The LPT System database design shall utilize mechanisms designed to protect data integrity including but not limited to: normalized data, foreign key relationships, field-‐level value constraints, application user roles, data validation triggers, and use of materialized views and prevention of direct base table access by use of stored procedures and views.

401 13.5.14 The LPT System database design shall incorporate field-‐level validation whenever possible to limit the possibility of data entry or manual update errors; including but not limited to: foreign keys, dollar amount range checks, and telephone number and zip code masks.

402 13.5.15 For post-‐System & Operational Acceptance LPT System changes, prior to a change being implemented on a production database, a written test and acceptance plan shall be developed, executed and the results accepted in writing by OTA.

403 13.1 LPT System End User Requirements404 13.1.1 The LPT System shall employ a 100% browser based, graphical user

interface (GUI), or a comparable user interface of equal or greater quality and capability that does not require specialized software. A browser is defined as a software program that allows the user to open the GUI in a form that is suitable for display.

405 13.1.2 The LPT System shall be configurable and shall have appropriate interactive GUIs to allow authorized staff to manage the various configuration parameters required for proper LPT System operation.

406 14 Security 407 14.1 General Security Requirement408 14.1.1 The LPT Processor shall ensure the LPT System is secured against

unauthorized access, data loss, and data integrity loss. 409 14.1.2 The LPT Processor shall, at a minimum, adhere to the OTA Information

Security Policy (see Appendix I) and Physical Security Policy (see Appendix J).

410 14.2 Access Security









Requirement



411 14.2.1 Access to the operating system, database, Virtual Private Network (VPN), and all other applications, shall be controlled by system administrators, on a per-‐user basis.

412 14.2.2 The LPT System shall ensure that all user access to any part of the LPT System, except for the customer-‐facing website, shall be managed from a single directory of authorized users. The LPT System must validate user accounts against a directory service. For example: if the agency disables or locks a user network account via active directory, the LPT application can test for an active, enabled user account. This is so credentials can be maintained in the LPT System but also checked for a valid directory account.

413 14.2.3 The authorized user directory shall be the authorization provider for, at a minimum, operating system access, database level access, remote access, and access to the user-‐level application.

414 14.2.4 All updates to the authorized user directory shall be securely logged. 415 14.2.5 System administrator logs and other logs shall be monitored for

exceptions and/or improper activity and this log monitoring shall be documented and automated to the extent possible (e.g., use of system log monitoring tools).

416 14.2.6 Passwords shall be required for access to any part of the LPT System. 417 14.2.7 All accessible subsystems, including the customer-‐facing website, shall

have the ability to limit valid passwords by length and use of special characters, and to restrict repeated use of the same password by a single user.

418 14.2.8 All accessible subsystems, including the customer-‐facing website, shall have the ability to require passwords to be changed periodically.

419 14.2.9 LPT System functionality shall be secured by passwords and security roles.

420 14.2.10 The LPT System security role set shall include a role enabling its users to assign or remove security role(s) of other users.

421 14.2.11 The LPT System security role set shall include a role enabling its users to reconfigure the LPT System rights, which are enabled by other security roles.

422 14.2.12 The LPT Processor, in conjunction with OTA, shall develop LPT System rights and security roles during the design process.

423 14.2.13 The LPT Processor shall grant user access based on the OTA-‐approved Policies and Procedures.

424 14.2.14 The LPT System shall allow for role-‐based user access configuration.425 14.2.15 The LPT System shall require each user to have unique logon credentials.









Requirement



426 14.2.16 The LPT System shall allow user access to be controlled by a system administrator.

427 14.2.17 The LPT System shall automatically log database records for all user access and all user activity that results in data updates or access to customer data.

428 14.2.18 The LPT System shall provide functionality for searching the user access logs using commonly available file system or database utilities.

429 14.2.19 The LPT System shall provide controls to lock out users after a configurable number of unsuccessful system login attempts.

430 14.2.20 The LPT System shall provide tools that will detect and report any intrusions and/or attempted intrusions.

431 14.3 Data Security432 14.3.1 The LPT Processor shall be responsible for all aspects of protecting LPT

System data.433 14.3.2 The LPT Processor shall employ methods to ensure reliable data

communications, file transfer and integrity of the database and tools that detect interruption of these.

434 14.3.3 The LPT Processor shall provide and implement a systematic method for archiving and purging data and ensure that the entire LPT System software and data is backed-‐up and stored at an off-‐site location.

435 14.3.4 The LPT Processor shall ensure that application activity is logged in a common log file format with searchable, and human-‐readable log files.

436 14.3.5 The LPT Processor shall configure all operating systems and databases such that all non-‐essential users, features, and services are either locked or removed.

437 14.3.6 The LPT Processor shall strengthen all operating system and database passwords, including passwords for LPT System and application users, in accordance with industry best practices.

438 14.3.7 The LPT Processor shall ensure that system administrator level access is limited, and that any administrator level access is logged.

439 14.3.8 The LPT Processor shall ensure that operating systems and databases are up to date with the latest security patches.

440 14.3.9 The LPT Processor shall employ an auditing strategy for the LPT System that maximizes the possibility of detecting unauthorized activity. This shall include an automated event notification and logging process.

441 14.3.10 The LPT System shall allow the LPT Processor to create user roles and assign/restrict account access and management rights according to training and Policies and Procedures that are documented by the LPT Processor and approved by OTA.









Requirement



442 14.3.11 The LPT System shall support configuration of user roles that limits access to sensitive data in compliance with PCI requirements.

443 14.3.12 The LPT Processor shall ensure that all Microsoft Windows servers and workstations used on the Project have up-‐to-‐date virus protection and security management software that are monitored and managed via centrally managed back end software and/or MOMS.

444 14.4 Payment Card Industry Data Security Standard (PCI DSS)445 14.4.1 All systems provided and data maintained by the LPT Processor shall be

continually in full compliance with the most current PCI DSS at all times. 446 14.4.2 The LPT System shall provide for OTA’s classification as a Level 1

merchant as defined in PCI DSS.447 14.4.3 The LPT Processor shall retain a highly qualified and credentialed 3rd

party firm to annually certify that all systems provided by the LPT Processor and all processes operated by the LPT Processor meet the PCI DSS requirements. OTA shall approve the PCI DSS compliance subcontractor, and the cost of annual exams shall be borne by the LPT Processor.

448 14.4.4 The LPT Processor shall provide to OTA prior to Go-‐Live and annually thereafter, the compliance subcontractor’s report detailing the compliance, including identifying the version of PCI DSS compliance with which each system or process complies.

449 14.4.5 The LPT Processor shall resolve compliance exceptions in accordance with the Performance Standards. The LPT Processor shall bear the cost of resolving all compliance exceptions including costs related to changes to PCI DSS standards.

450 15 System Administration & Maintenance451 15.1 General System Administration & Maintenance Requirements452 15.1.1 The LPT Processor shall be responsible for the resolution of all LPT

System issues, Software bugs, required upgrades, users, passwords and LPT System security.

453 15.1.2 The LPT Processor shall develop a System Administration Manual that details the LPT System administration and maintenance procedures.

454 15.1.3 The LPT Processor shall ensure that file systems and the databases always have adequate space available.

455 15.1.4 The LPT Processor shall monitor LPT System resources including CPU usage, memory usage, network performance, and swap space.

456 15.1.5 The LPT Processor shall provide LPT System software maintenance, LPT System hardware maintenance, as well as any third party hardware and software maintenance contracts.

457 16 Disaster Recovery/Business Continuity









Requirement



458 16.1 General Disaster Recovery/Business Continuity Requirements459 16.1.1 The LPT Processor shall ensure continuous ongoing operations in the

event of a disaster or other event that disrupts regular business operations.

460 16.1.2 The LPT Processor shall provide to OTA a comprehensive Disaster Recovery/Business Continuity plan detailing the process for continued LPT operations and performance of critical business functions in the event of an unscheduled service disruption regardless of the duration.

461 16.1.3 The LPT Processor shall ensure that a OTA approved Disaster Recovery/Business Continuity Plan is in place and fully tested and approved prior to Go-‐Live.

462 16.1.4 The Disaster Recovery/Business Continuity plan shall include, but not be limited to, the following:

463 16.1.4.1 Events and situation that will trigger the Disaster Recovery/Business Continuity process

464 16.1.4.2 Process management465 16.1.4.3 Contact list and notification process 466 16.1.4.4 Methodology for the full recovery of key components of the LPT

System within required time periods 467 16.1.4.5 Plan/alternative for resuming external interfaces and communications

468 16.1.4.6 Staffing 469 16.1.4.7 Off-‐site storage of all LPT System software, documentation,

agreements and data 470 16.1.4.8 Technical and operations support471 16.1.4.9 Routine off-‐site back-‐up472 16.1.4.10 Data recovery/restoration473 16.1.4.11 Alternate sites 474 16.1.4.12 A new LPT System 475 16.1.4.13 Transfer of critical functionality to a new LPT System capable of

running the identical (or recovered) operating systems, applications, and databases

476 16.1.4.14 Customer notification477 16.1.4.15 Test program 478 16.1.4.16 Return to normal operations 479 16.1.5 The LPT Processor shall ensure that all necessary measures are in place

to implement any and all elements of the Disaster Recovery/Business Continuity Plan as needed throughout the Term.









Requirement



480 16.1.6 In the event of a disaster or interruption in business services the LPT Processor shall implement the Disaster Recovery/Business Continuity Plan. When the event is over, the LPT Processor shall document lessons learned and update the Disaster Recovery/Business Continuity Plan in accordance with those lessons.

481 16.1.7 The LPT Processor shall prepare and perform periodic tests of its Disaster Recovery/Business Continuity Plan.

482 16.1.8 Authorized OTA staff shall be provided complete access to observe all Disaster Recovery/Business Continuity test activities.

483 16.1.9 At the completion of each test, the LPT Processor shall submit to OTA, a comprehensive report detailing the results of all tests and any corrective actions required with specific timeframes for completions.

484 16.1.10 The LPT Processor shall update the Disaster Recovery/Business Continuity Plan at least once per year and within 30 days of any major LPT System or hardware change and/or after a disruption in business.

485 16.1.11 Following are the recovery time standards:486 16.1.11.1 Call center: 72 hours487 16.1.11.2 Payment processing: 72 hours488 16.1.11.3 Correspondence: 5 Business Days 489 16.1.11.4 Reporting: 5 Business Days490 16.1.11.5 Finance tasks 5: Business Days491 16.1.11.6 LPT System functions*: 72 hours

*LPT System functions include, but are not limited to, the following.-‐ Transaction processing-‐ Website-‐ CSR access to all screens and functions-‐ Image Review-‐ Remote access by OTA to all screens and functions-‐ Invoice and violation notice generation-‐ All invoice and violation notice generation related activities

492 16.1.12 All data shall be backed up at an off-‐site location such that it can be completely restored on an identical LPT System. This process shall ensure that no data is lost in the event of a LPT System malfunction, disaster or malicious interference with the LPT System.

493 16.1.13 LPT System disaster recovery operations shall allow for the complete restoration of the LPT System.

494 17 Documentation495 17.1 Policies and Procedures Review









Requirement



496 17.1.1 The LPT Processor shall develop and maintain Policies and Procedures documents that define all ongoing operational policies, procedures and processes of the LPT Operation.

497 17.1.2 The Policies and Procedures documentation shall include operating policy, approved Business Rules and specific procedures required in the performance of all LPT activities, including a detailed description of transaction and data flow processing.

498 17.1.3 The Policies and Procedures shall encompass all operations covered by the LPT Processor and its third-‐party contractors (e.g., mail house), including all daily responsibilities and periodic tasks.

499 17.1.4 The Policies and Procedures shall include:500 17.1.4.1 All LPT program policies 501 17.1.4.2 All LPT Processor procedures502 17.1.4.3 All customer materials and correspondence and the policy for their use

503 17.1.4.4 Dispute Matrix504 17.1.4.5 Customer Authentication Matrix505 17.1.4.6 All scripts for common customer service functions, automated

recordings, and the detailed IVR system menu tree and script506 17.1.4.7 Image review business rules507 17.1.4.8 Web page layouts, content and links508 17.1.4.9 Samples of all reports, spreadsheets, and reconciliations 509 17.1.4.10 All required processing timelines510 17.1.4.11 All Performance Standards and measurement methods511 17.1.4.12 LPT Processor information technology procedures for network

management, database management, server and PC patching and security.

512 17.1.4.13 Legal constraints513 17.1.4.14 Privacy handling and other applicable internal controls514 17.1.4.15 PCI compliance information515 17.1.4.16 Data security516 17.1.5 The Policies and Procedures shall reflect configurations and LPT System

functionality from the current RTM and SDD. 517 17.1.6 The Policies and Procedures shall include the LPT Processor’s process and

schedule for updating and amending all operations documentation on an on-‐going basis, including but not limited to the Policies and Procedures, user manuals, and disaster recovery plan.

518 17.1.7 In accordance with the approved Project Schedule, the LPT Processor shall deliver preliminary Policies and Procedures documents.









Requirement



519 17.1.8 After receipt of comments from OTA, the LPT Processor shall, as requested by OTA, participate in working sessions with OTA to review the preliminary Policies and Procedures.

520 17.1.9 The LPT Processor shall incorporate all revisions, as appropriate, based on comments and input from the working sessions and deliver updated Policies and Procedures documents to OTA for review and approval.

521 17.1.10 An updated version of the Policies and Procedures shall be provided to OTA for approval on an annual basis or in advance of any material policy or procedural change, or more often as requested by OTA.

522 17.2 Manuals 523 17.2.1 The LPT Processor shall develop and provide a complete set of LPT

System documentation and user/training manuals in electronic and hardcopy format.

524 17.2.2 The LPT Processor shall provide user/training manuals for different user types such as, but not limited to, CSRs, image reviewers, system administrators, payment processors, auditors, and accounting staff.

525 17.2.3 The manuals shall include instructions for the use of the relevant aspects of the LPT System, report access levels and descriptions of reports relevant to each user type.

526 17.2.4 The LPT Processor shall provide administration manuals for the website and the IVR system.

527 17.2.5 The LPT Processor shall provide a separate Reports User Manual that includes directions for using the ad hoc reporting system.

528 17.2.6 The LPT Processor shall provide to OTA comprehensive data dictionaries of all CSC databases including descriptions and information about relationships, keys, relational and validation constraints for fields, indexes, tables, views, schemas, triggers, procedures, materialized views, scheduled jobs, directories and any other relevant database objects.

529 17.2.7 The LPT Processor shall provide and obtain OTA approval of training manuals prior to the start of training.

530 17.2.8 The LPT Processor shall provide all approved manuals to OTA at least one month prior to Go-‐Live. In addition, an updated version of all manuals shall be provided to OTA for approval on an annual basis, upon any material change, or more often as requested by OTA.

531 18 Administrative Requirements532 18.1 General Administrative Requirements533 18.1.1 The LPT Processor shall be responsible for the administration,

management, performance and maintenance of all LPT activities.









Requirement



534 18.1.2 The LPT Processor shall have up-‐to-‐date knowledge of the regulations and laws relative to the Project and ensure that the LPT operation is in compliance with those regulations and laws.

535 18.1.3 The LPT Processor’s CSC staff shall not engage in any other business activities while acting in this capacity.

536 18.1.4 As directed by OTA, the LPT Processor shall research, compile and provide data to OTA in response to Oklahoma Opens Records Requests, subpoenas, search warrants, law enforcement requests or other requests. The LPT Processor shall track, document and report to OTA the status of all such requests on a monthly basis.

537 18.1.5 The LPT Processor shall be responsive to all OTA inquiries for information, research, and other queries during normal business hours and shall have a process available for responding to emergency queries after normal working hours.

538 18.2 Staffing539 18.2.1 The LPT Processor shall provide qualified personnel sufficient in quantity

and expertise and experience to meet the requirements of this Scope of Services and in compliance with an approved Staffing Plan.

540 18.2.2 The LPT Processor shall name individuals to positions identified and described in its organization chart as Key Personnel.

541 18.2.3 LPT Processor personnel that interact directly with the public shall perform in a professional manner at all times.

542 18.2.4 The LPT Processor shall be responsible for all staffing requirements necessary to support the full operation of the LPT Operation, except as specifically indicated, and to meet or exceed all required Performance Standards.

543 18.2.5 The LPT Processor shall conduct a criminal background check of all License Plate Tolling Processor’s staff immediately prior to employment. The LPT Processor shall certify to OTA that all staff has passed the required background checks.

544 18.2.6 All staff shall have the appropriate skill, training, background, knowledge, experience, integrity and character necessary to provide the required services in a competent and professional manner.

545 18.2.7 All LPT Processor staff that interface with the public shall be able to communicate in the English language.

546 18.2.8 The LPT Processor shall remove any staff member whose qualifications or conduct, in the opinion of OTA, is not appropriate or commensurate with their position.









Requirement



547 18.2.9 The LPT Processor shall be responsible for all wages and payroll expenses associated with staffing the License Plate Tolling Operation. Staff of the LPT Processor and/or its Subcontractors and suppliers shall not be considered employees of OTA.

548 18.3 Training549 18.3.1 The LPT Processor shall establish and implement a training program for

each position and function. 550 18.3.2 The LPT Processor shall attend annual security awareness training as

prescribed by Payment Card Industry Data Security Standards (PCI DSS) requirements.

551 18.3.3 All staff shall be fully and properly trained prior to working on the Project. In addition to initial training, all staff shall be informed of any changes to the OTA LPT Program and/or any situations that affect the public and shall be provided instructions and scripts on communicating those changes in a consistent manner.

552 18.3.4 The LPT Processor shall provide formal CSR training prior to changes to the LPT System that impact the CSR’s use of the LPT System.

553 18.3.5 The LPT Processor shall notify OTA at least one week prior to all scheduled training so that up to three OTA representatives may observe, monitor or participate in any and all training courses or seminars.

554 18.3.6 The LPT Processor shall provide training to OTA staff on the use of CSR screens, finding and using standard reports, generating ad-‐hoc reports, the structure of the database, LPT Policies and Procedures or other topics determined to be of utility to OTA staff.

555 18.3.7 The LPT Processor shall provide training that utilizes both classroom training and hands on LPT System training, sufficient to ensure that LPT Processor and OTA staff are proficient in the use of the LPT System.

556 18.3.8 The LPT Processor shall develop and provide all materials, equipment, and facilities required for training.

557 18.3.9 The LPT Processor shall ensure that all training programs reflect current Policies and Procedures and identify the responsibilities of each employee with regard to theft, fraud, embezzlement, fiscal misconduct, customer confidentiality and/or violation of OTA and LPT policies.

558 18.4 Document Control559 18.4.1 The LPT Processor shall control and keep current all manuals and

documents related to LPT operations. 560 18.4.2 All incoming and outgoing customer correspondence shall be

electronically associated with customer accounts and available online in the customer account.









Requirement



561 18.4.3 The LPT Processor shall keep all records and reports related to LPT operations in accordance with the data retention requirements.

562 18.4.4 The LPT Processor shall safely and securely store all documents, e.g. applications, customer correspondence, forms, financial documents and any documents generated or received by the LPT Processor.

563 18.4.5 The LPT Processor shall file stored documents in a manner that facilitates easy retrieval by subject, type and/or date. Following the period of storage, the LPT Processor shall be responsible for the timely, secure destruction and disposal of documents.

564 18.4.6 All documents subject to destruction shall be mechanically shredded or turned over to a professional document disposal service.

565 18.4.7 The LPT Processor shall notify OTA at least 30 days prior to the scheduled destruction of any stored document and the LPT Processor shall notify OTA once the documents have been destroyed.

566 18.4.8 The LPT Processor shall not destroy any documents or files without the written consent of OTA.

567 18.5 Customer Information and Privacy568 18.5.1 The LPT Processor shall consider all LPT data as confidential and maintain

all data in a secure manner that protects personal identification/identity information using state of the art data security measures.

569 18.5.2 All customer information is confidential and shall not be disclosed or released unless requested by the specific customer or unless directed by OTA.

570 18.5.3 The LPT Processor shall refer all external requests, inquiries, subpoenas and other official information requests to designated OTA management staff. OTA shall be immediately notified of such requests.

571 18.5.4 The LPT Processor shall not communicate, respond to inquiries, or provide information to the media, other government agencies, or individuals representing organizations other than in the normal course of customer service.

572 18.5.5 The LPT Processor shall immediately notify OTA of all requests that are outside of the normal course of customer service.

573 18.5.6 Responding to all inquiries and communications, other than in the normal course of customer service, will be the responsibility of OTA unless the LPT Processor is specifically directed by OTA to respond.









Requirement



574 18.5.7 The LPT Processor shall establish and implement reasonable methods to verify the identity of customers prior to release of information. A customer authentication matrix, detailing the various levels of information that can be released based on authentication level, shall be developed by the LPT Processor, approved by OTA and included in the Policies and Procedures.

575 18.5.8 The LPT Processor shall not sell, use, or distribute general or specific customer information and data externally for any reason, nor shall it aggregate the data for any non-‐permitted use.

576 18.5.9 The LPT Processor shall handle all customer and account information in accordance with the OTA privacy policy, and approved customer account terms and conditions.

577 18.5.10 Destruction shall be documented and periodically reported to OTA. 578 18.5.11 A written procedure to ensure proper destruction of customer data in

accordance with OTA policy shall be included in the Policies and Procedures developed by the LPT Processor and approved by OTA. The procedure shall define who is responsible for executing the applicable information purges, a method for recording/documenting when purges occur, who is responsible for recording the action and where records of the purge are maintained.

579 18.6 Agency Access580 18.6.1 The LPT Processor shall provide authorized OTA staff with remote, real

time, secure, browser-‐based access into the LPT System to provide customer service, research issues, run reports and perform quality assurance/audit reviews.

581 18.6.2 The LPT Processor shall provide OTA with various levels of user access privileges commensurate with OTA staff job requirements. The specific access levels shall be defined during the design phase.

582 18.6.3 OTA remote access shall include, but not be limited to:583 18.6.3.1 Read only access to account data within the LPT System.584 18.6.3.2 The ability to input search criteria and perform account information

and research queries and searches.585 18.6.3.3 The ability to insert notes into customer accounts.586 18.6.3.4 The ability to correct or override entries or postings. 587 18.6.3.5 The ability to generate and retrieve reports in all required formats. 588 18.6.3.6 Ad-‐hoc reporting capabilities with full access to the Reporting

Database.589 18.6.3.7 The ability to print all reports remotely to any printer.590 18.6.3.8 Dashboard access.









Requirement



591 18.6.4 Authorized OTA users shall be issued user names and passwords in accordance with the established LPT System account access rules.

592 18.6.5 Authorized OTA staff shall have full access (announced and unannounced) to the LPT Processor’s offices and operation for any purpose including quality assurance, internal audit, and observation and monitoring.

593 18.6.6 The LPT Processor shall provide OTA with workspace (chair and desk) and network access in those offsite facilities in the event that OTA representatives visit those facilities.

594 18.6.7 OTA shall have the right to inspect the facilities at any time and require the LPT Processor to correct any condition that, in the opinion of OTA, represents safety and/or security concerns and/or is not in keeping with OTA’s public image.

595 18.6.8 The LPT Processor shall have staff available to support OTA staff by demonstrating and explaining systems and procedures, and answering questions.

596 19 LPT Physical location 597 19.1 General LPT Physical location Requirements598 19.1.1 The LPT Processor is responsible for establishing, furnishing, supplying,

maintaining, staffing, sizing and operating all facilities as needed to meet the requirements of this Scope of Services.

599 19.1.2 The LPT Processor shall establish, furnish, supply, maintain, staff, and operate the physical location in accordance with all requirements and Performance Standards.

600 19.1.3 The LPT physical location shall be of appropriate size to conduct all required LPT operations, house all necessary staff and allow for reasonable expansion and contraction in capacity as the OTA LPT Program evolves.

601 19.1.4 The LPT Processor shall ensure all locations provided by the LPT Processor are Americans with Disabilities Act (ADA) compliant throughout the Term.

602 19.1.5 The LPT Processor shall ensure that all locations provided or used by the LPT Processor are professional in appearance and clean.

603 19.1.6 The LPT physical location shall be available prior to the Production Readiness Test to allow for hiring and training, and to support Production Readiness Testing.

604 19.1.7 The LPT Processor shall provide all furnishings, fixtures, office equipment, computer hardware, signage, supplies, utilities, building services, and physical security and security related to the operation to all LPT Processor provided facilities.









Requirement



605 19.1.8 LPT Processor shall provide and maintain all required connectivity and telephone lines, including connections to OTA, the Host and/or third party networks that provide speed and capacity sufficient to ensure all functions can be performed with no delay and with adherence to all data and privacy security requirements.

606 19.1.9 The LPT Processor shall ensure all computer hardware is protected by a UPS with surge protection and battery backup.

607 19.1.10 The LPT Processor shall be responsible for any required build-‐out and/or leasing of office space.

608 19.2 Physical Security609 19.2.1 The LPT Processor shall be fully responsible for the physical security of

the LPT facilities and all related property, assets, data and funds. 610 19.2.2 The LPT Processor shall utilize security measures and devices including,

but not limited to, site access controls, data access controls, safes, vaults, surveillance cameras, environmental controls, data security, inventory security, software security and other tools that will prevent, detect, and/or assist in researching and investigating issues at all LPT locations.

611 19.2.3 The LPT Processor shall ensure that the physical security controls meet all PCI DSS requirements.

612 19.2.4 The LPT Processor shall be responsible for the custody of funds and shall provide internal control and security practices to protect the receipt, storage, and transfer of funds.

613 19.3 Operating Hours614 19.3.1 The LPT Processor’s live CSR call center shall be available to customers

Monday through Friday (excluding holidays), 08:00 -‐ 16:30 CST. 615 19.3.2 The IVR and website shall be available 24 hours a day, 7 days a week

except for approved scheduled outages for maintenance and system updates.

616 19.3.3 LPT Processor management staff shall be available during regular hours of operation and shall be available 24/7 to respond to emergency situations.

617 20 Transaction Processing618 20.1 General Transaction Processing 619 20.1.1 The LPT Processor shall process all transactions received from the Host as

described in this document and its appendices.620 20.1.2 The LPT System shall process all transactions in accordance with the most

recent OTA toll rate schedule, provided by OTA.621 20.2 Image Review









Requirement



622 20.2.1 The LPT Processor shall establish and implement a process to correctly identify the license plate number, jurisdiction and plate type of each license plate image provided by OTA. This may include processes such as Optical Character Recognition (OCR), fingerprinting and manual image review.

623 20.2.2 The LPT Processor’s image review process shall achieve a license plate (number, jurisdiction and plate type) accuracy rate of 99.95% of all readable images.

624 20.2.3 The LPT Processor shall perform image review for all images by processing the oldest transaction date first.

625 20.2.4 The LPT System shall allow users to perform image enhancements to improve the readability of images.

626 20.2.5 The LPT System shall allow users to simultaneously view all images related to a particular transaction.

627 20.2.6 The LPT Processor shall assign an appropriate reject reason, based on a list of reject codes and processing rules to be developed with OTA, to all transactions for which viable license plate information cannot be determined from the available images.

628 20.2.7 The LPT System shall allow for a minimum of 10 distinct image reject codes, to be defined with and approved by OTA during the design stage.

629 20.2.8 The LPT System shall reconcile the reject codes to OTA at the transaction level, for all transactions that are rejected.

630 20.2.9 The LPT System shall allow rejected images to be reviewed for quality assurance purposes.

631 20.2.10 The LPT Processor shall monitor and report on the quality of images received from the lane system in a manner that allows for the quick escalation of in-‐lane camera issues to OCR issues.

632 20.2.11 The LPT System shall automatically queue all previous DMV rejects for manual re-‐review, based on a configurable number of retries per transaction.

633 20.2.12 The LPT System shall allow the number of image review retries to be set to zero.

634 20.2.13 The LPT Processor shall associate the observed license plate number, plate type (where applicable), and jurisdiction to all transactions for which those data can be determined from the available images.

635 20.2.14 The LPT Processor shall provide Image Review reports to be developed with OTA during the design stage.

636 20.2.15 The LPT Processor shall document and adhere to Image Review Policies and Procedures that will be developed with and approved by OTA.









Requirement



637 20.2.16 The LPT Processor shall retain all images, including rejected images, according to OTA’s data retention policy.

638 20.3 LPT Watch List639 20.3.1 The LPT System shall maintain a manual list of license plate / vehicle

information (string, jurisdiction, and type) records. 640 20.3.2 The LPT System shall allow authorized LPT Processor and OTA users to

access the Watch List and add/remove records.641 20.3.3 The LPT System shall require all transactions with license plate

information matching to a Watch List record to go through the manual image review process, regardless of the OCR confidence data associated with the transaction/images.

642 20.4 PIKEPASS Account Match Processing643 20.4.1 The LPT System shall compare each license plate associated with a

transaction to the current list of V-‐Toll eligible license plates to determine the appropriate method for processing each transaction.

644 20.4.2 The LPT System shall send all V-‐Toll eligible transactions to OTA for processing.

645 20.4.3 The LPT System shall process all other (not V-‐Toll eligible) transactions as described in this document.

646 20.4.4 The LPT System shall reconcile these V-‐Toll eligible transactions back to OTA.

647 20.4.5 The LPT System shall not process V-‐Toll transactions to LPT accounts. 648 20.5 Name and Address Acquisition via Registered Owner of Vehicle (ROV)

Lookup649 20.5.1 The LPT Processor shall establish and implement a process for using

license plate number, issuing jurisdiction, and plate type (where applicable) to obtain the name and address of the registered owner of vehicles from the appropriate DMV and/or other third party services in all 50 states, Washington D.C., all Canadian Provinces, and all Mexican states where possible.

650 20.5.2 For license plates that cannot be processed to a PIKEPASS account, the LPT System shall access an OTA database to obtain Oklahoma, Texas and Commercial vehicle registered owner name and address information.

651 20.5.3 For license plates outside of Oklahoma and Texas that cannot be processed to a PIKEPASS account the LPT System shall submit vehicle information to the ROV source for registered owner name and address information.

652 20.5.4 The LPT Processor shall utilize plate type (DMV categorization of license plates) in its submissions for all states that require or accept plate type as a means of ensuring the highest and most accurate return rate.









Requirement



653 20.5.5 The LPT Processor shall be capable of submitting requests to several DMV databases where applicable (for example, individual, commercial, apportioned) to ensure the highest and most accurate return rate.

654 20.5.6 The LPT Processor may utilize the OTA out-‐of-‐state ROV look up vendor.655 20.5.7 When multiple transactions for the same license plate information

require ROV lookup at the same time, the LPT Processor shall initiate only one request for that particular plate and apply the results to each transaction, if doing so will reduce costs incurred by OTA.

656 20.5.8 The LPT Processor shall track all DMV and other source requests to their disposition, including hits, no hits, rejected license plates and no responses by state/province and by source.

657 20.5.9 For transactions that reject or receive no response from an ROV source lookup, the LPT Processor shall use other ROV sources and methods available (e.g., skip tracing) to attempt to locate the responsible owner, in accordance with Policies and Procedures to be approved by OTA.

658 20.5.10 The LPT Processor shall report to OTA the specific reasons for all failures to obtain the ROV, including by source, reason, jurisdiction, and plate type and with an indication of whether the request was a first submission, resubmission, or was never successfully submitted.

659 20.5.11 The LPT Processor shall use methods or services approved by OTA to perform uniform address cleansing of data returned from ROV sources.

660 20.5.12 The LPT System shall have the ability to allow authorized users to override the address field based on approved customer requests.

661 20.5.13 The LPT System shall associate the information related to the ROV request to the transaction(s) for which that lookup was initiated.

662 20.5.14 The LPT System shall associate the ROV information returned for a particular lookup with the transaction(s) for which that lookup was initiated.

663 20.6 LPT Transaction Processing664 20.6.1 When the LPT System obtains ROV information for a transaction, the LPT

System shall check existing unregistered LPT accounts (UPAs) for an exact match to the name, address, and vehicle information.

665 20.6.2 If the LPT System identifies an existing UPA with an exact match for the name, address, and license plate information, the LPT System shall process the transactions to that UPA.

666 20.6.3 If the LPT System identifies an existing UPA with an exact match for the name and license plate information, but a different address, the LPT System shall update the address on that UPA and process the transaction to that account.









Requirement



667 20.6.4 If the LPT System determines there is no existing UPA with the exact license plate information and registered owner name, the LPT System shall establish a new UPA for the license plate and ROV information and process the transaction to the new account.

668 20.7 LPT Invoice Account Establishment 669 20.7.1 The LPT System shall automatically create new UPAs as dictated by the

transaction processing requirements. 670 20.7.2 The LPT System shall not allow customers or LPT Processor staff to

manually establish or close an UPA.671 20.7.3 The LPT System shall assign new UPA account numbers sequentially, in

order of establishment.672 20.7.4 The LPT System shall not allow any UPA to have the same account

number as any other UPA or PIKEPASS account.673 20.7.5 The LPT System shall use the license plate information associated with a

transaction and the ROV information returned by the ROV source to populate the new UPA.

674 20.7.6 The LPT System shall issue an OTA-‐approved ‘welcome letter’ to the name/address returned by ROV lookup after the LPT System establishes a new UPA. The timing of issuing the welcome letter will be determined during design.

675 21 Invoice Generation and Escalation676 21.1 Invoice Generation and Issuance 677 21.1.1 The LPT System shall accumulate LPT transactions on each UPA and

generate an invoice for unpaid amounts at the end of the configurable invoice cycle.

678 21.1.2 The LPT System shall allow for the configurable invoice cycle for the initial invoice to be different than the configurable invoice cycle for all subsequent invoices.

679 21.1.3 The LPT System shall generate the initial invoice on a new UPA after the end of the initial invoice cycle.

680 21.1.4 The LPT System shall generate all subsequent invoices (after the initial) for an UPA after the end of the invoice cycle.

681 21.1.5 The LPT Processor shall have the ability to issue invoices to an email address on file with an UPA, in place of a paper mailing, for accounts opted-‐in for emailed invoices.

682 21.1.6 The LPT Processor shall have the capability to provide a link within invoice emails, providing customers access to their online invoice and payment options, with the required credentials for web access.









Requirement



683 21.1.7 The LPT System shall allow CSRs to flag accounts (opt-‐in) for email invoice delivery, upon customer request and according to Policies and Procedures to be approved by OTA.

684 21.1.8 The LPT Processor shall be capable of selecting accounts with invoices eligible for inclusion of supplemental materials by account variables such as zip code, toll activity, fees, and account status.

685 21.2 Invoice Issuance Suppression686 21.2.1 The LPT System shall provide the functionality to suppress the issuance

of invoices with outstanding amounts below a configurable threshold specified by OTA.

687 21.2.2 The LPT System shall provide functionality to suppress the issuance of invoices for particular accounts, at the account level, at the request of OTA.

688 21.2.3 The LPT Processor shall provide the functionality to suppress the issuance of invoices with no toll or financial activity during the invoice period.

689 21.2.4 For accounts with invoice issuance suppressed, the LPT System shall generate the invoice data and associate it with the account but shall not issue the invoice (via mail or email).

690 21.2.5 The LPT System shall clearly indicate in the account record whether the account has invoice issuance suppressed, along with the reason for that suppression.

691 21.2.6 The LPT System shall suppress customer mailings that are returned as undeliverable after a configurable number of mailing attempts to the same address.

692 21.2.7 The LPT System shall have the capability to manually override mail suppression at the account level.

693 21.2.8 For accounts with invoice mailing suppressed due to returned/undeliverable mail, the LPT System shall have the capability to escalate unpaid amounts.

694 21.3 Invoice Layout Requirements695 21.3.1 On each invoice, the LPT Processor shall provide individual transaction

details, including time, date, toll location, vehicle class, license plate information, and toll amount.

696 21.3.2 The LPT Processor shall display all toll transaction times in Central Time. 697 21.3.3 On each invoice, the LPT Processor shall have the ability to include UPA-‐

specific data, including but not limited to:698 21.3.3.1 invoice date 699 21.3.3.2 invoice period700 21.3.3.3 invoice number









Requirement



701 21.3.3.4 PIN for IVR/web access702 21.3.3.5 due date 703 21.3.3.6 registered owner name704 21.3.3.7 registered owner mailing address705 21.3.3.8 amount due (new tolls due and total due) for the current invoice cycle

706 21.3.3.9 amounts due from prior invoice cycles (tolls and fees) broken down by invoice cycle

707 21.3.3.10 amounts due broken down by past due time periods (e.g., past due, 30 days past due, 60 days past due)

708 21.3.3.11 amount in collections709 21.3.3.12 payments received since the issuance of the prior invoice710 21.3.3.13 amounts in violation status (by violation notice level, 1st and 2nd)711 21.3.3.14 vehicle registration stop flag status712 21.3.4 On each invoice, the LPT Processor shall have the ability to include

general information, including but not limited to:713 21.3.4.1 Customer Service telephone number 714 21.3.4.2 Customer Service website URL715 21.3.4.3 payment instructions716 21.3.4.4 PIKEPASS account information717 21.3.4.5 escalation timelines and penalties718 21.3.4.6 applicable laws and legal means available to OTA for collecting unpaid

tolls719 21.3.4.7 dispute instructions 721 21.3.5 The LPT Processor shall have the ability to include a barcode that

uniquely identifies the invoice.722 21.3.6 The LPT System shall support a distinct document layout for invoices that

include tolls only.723 21.3.7 The LPT System shall support a distinct document layout for invoices that

include fees.724 21.3.8 The LPT System shall support a distinct document layout for invoices that

include violations.725 21.3.9 The LPT System shall support a distinct document layout for invoices

issued for UPAs with a vehicle registration stop flag placed.726 21.3.10 The LPT System shall support a distinct document layout for invoices

issued for UPAs with amounts due open with a Collections agency.727 21.3.11 The LPT Processor shall work collaboratively with OTA in the design,

format and content of all invoices (email and paper), envelopes, and any related materials or inserts during the design phase and subject to the approval of OTA.









Requirement



728 21.3.12 The LPT Processor shall be capable of inserting (for paper statements) or attaching (for email statements) other materials in or with selected customer statements as directed by OTA.

729 21.4 Customer Fees 730 21.4.1 The LPT System shall allow for the assessment of customer fees. 731 21.4.2 The LPT System shall allow all fee amounts and the timing of assessment

to be configurable.732 21.4.3 The LPT System shall provide for all fee amounts to be separately

configured.733 21.4.4 The LPT System shall allow authorized users to reverse and/or adjust any

fee.734 21.5 Invoice Escalation735 21.5.1 The LPT System shall set an invoice payment due date for each invoice (a

configurable number of days from that particular invoice’s issuance date) that will be visible to customers on their invoices.

736 21.5.2 The LPT System shall include an invoice payment “grace period” (a configurable number of days from an invoice due date) that will not be visible to customers. The invoice escalation process shall be based on the amounts that are unpaid at the end of the grace period.

737 21.5.3 The LPT System shall process amounts that remain unpaid for a particular invoice cycle through the escalation process independent of unpaid amounts from other invoice cycles.

738 21.5.4 The LPT System shall include tolls that are not paid in full at the conclusion of the grace period on the next month’s invoice, and shall assess a late fee (configurable amount) for those outstanding tolls.

739 21.5.5 The LPT System shall escalate all tolls and fees that appeared on the Unpaid Invoice at the same time, prior to generation of the New Invoice, regardless of the occurrence date or posting date of any particular toll or fee.

740 21.5.6 The LPT System shall be able to accommodate the invoice/violation escalation process detailed in Table 2. The exact escalation process and related timing will be defined during the design phase.

741 Table 2 See Table 2: Escalation Process tab. 742 21.5.7 The LPT System shall allow for all unpaid amounts to display on an

invoice broken down by invoice period and escalation level. 743 21.5.8 The LPT System shall have the capability to assess all past due and

escalation fees at any stage in the escalation process. 744 21.5.9 The LPT System shall have the capability to assess past due and other

escalation-‐related fees.









Requirement



745 21.5.10 The LPT System shall have the capability to change where escalation fees are assessed in the escalation process.

746 21.5.11 The LPT System shall have the capability to assess a violation fee for any invoice escalated to a violation.

747 21.5.12 The LPT System shall reflect associated fees on invoices, violation notices, and other correspondence as appropriate.

748 21.5.13 The LPT System shall allow for the assessment of configurable invoice late fees at the transaction level and the invoice level.

749 21.5.14 The LPT System shall allow for unpaid tolls and fees to be grouped, escalated and displayed on invoices by the period for which they were originally invoiced.

750 21.5.15 The LPT System shall allow for violations to be included on invoices as well as being issued as a separate violation notice.

751 21.5.16 The LPT System shall allow for a separate violation notice to be generated and issued for tolls and fees due for each invoice period.

752 21.5.17 The LPT System shall only generate and issue a violation notice if the violation amounts due are in excess of a configurable minimum amounts. The configurable minimum amounts shall be separate for tolls and fees.

753 21.5.18 The LPT System shall allow for the escalation of amounts due to an OTA specified Collection Agency.

754 21.5.19 The LPT System shall escalate amounts due to the Collection Agency only if the amounts due are in excess of a configurable minimum amounts. The configurable minimum amounts shall be separate for tolls and fees.

755 21.5.20 The LPT System shall allow for the assessment of a Collection Agency fee.

756 21.5.21 The LPT System shall allow for the assessment of a configurable Collection Agency fee that is based on a percentage of the total amounts due, a flat fee for the invoice period and/or a per-‐transaction fee.

757 21.5.22 The LPT System shall allow for a vehicle registration Stop Flag to be placed on Oklahoma license plate with amounts due in excess of configurable minimum amounts. The configurable minimum amounts shall be separate for tolls and fees.

758 21.5.23 The LPT Processor shall have a process to perform DMV registration holds or other OTA enforcement methods allowed by interstate interoperability enforcement agreements. The details of this process shall be determined during the design phase.









Requirement



759 21.5.24 The LPT System shall allow for the write-‐off of unpaid tolls and/or fees as dictated by the OTA-‐approved Policies and Procedures.

760 21.5.25 The LPT System shall have the ability to prevent disputed transactions from escalating until the dispute has been resolved.

761 22 Violation Processing762 22.1 Violation Processing 763 22.1.1 The LPT Processor shall be responsible for all violation processing,

including the generation and issuance of violation notices and applicable correspondence, payment processing, and all related customer service activities per the Oklahoma legislation (Appendix G).

764 22.1.2 The LPT System shall visually indicate to users whether an UPA has any outstanding amount due that has escalated to violation processing.

765 22.2 Violation Notice Generation and Issuance 766 22.2.1 The LPT Processor shall generate and issue all violation notices for LPT

violations.767 22.2.2 The LPT Processor shall issue all violation notices in the form of paper

notices.768 22.2.3 The LPT Processor shall issue paper violation notices even for accounts

with invoice mailing suppressed.769 22.2.4 The LPT Processor shall issue paper violation notices even for accounts

opted-‐in for email delivery of invoices.770 22.2.5 The LPT System shall include a configurable minimum dollar amount

required to issue a violation notice.771 22.2.6 The LPT System shall have the capability to suppress the issuance of

violation notices with outstanding amounts below a configurable threshold.

772 22.2.7 On each violation notice, the LPT Processor shall have the ability to include the following violation-‐specific information:

773 22.2.7.1 notice date774 22.2.7.2 notice due date 775 22.2.7.3 notice number776 22.2.7.4 PIN for IVR/web access777 22.2.7.5 time and date for each toll778 22.2.7.6 location for each toll779 22.2.7.7 axle count for each toll780 22.2.7.8 license plate image781 22.2.7.9 license plate number and state 782 22.2.7.10 vehicle make 783 22.2.7.11 vehicle owner name and address 784 22.2.7.12 amount due (tolls due, fees due, total due)









Requirement



785 22.2.7.13 barcode that uniquely identifies the violation notice786 22.2.8 On each violation notice, the LPT Processor shall have the ability to

include the following general information:787 22.2.8.1 payment instructions 788 22.2.8.2 escalation information 789 22.2.8.3 applicable laws 790 22.2.8.4 PIKEPASS account information791 22.2.8.5 OTA website URL 792 22.2.8.6 dispute information 793 22.2.8.7 Customer Service telephone number 794 22.2.9 The LPT Processor shall work collaboratively with OTA in the design,

format and content of all violation notices, envelopes, and any related materials or inserts during the design phase and subject to the approval of OTA.

795 22.2.10 The LPT System shall support distinct layouts for 1st violation notices and 2nd violation notices.

796 22.3 Violation Notices Tracking and Resolution 797 22.3.1 The LPT Processor shall update the status of each violation and violation

notice during its life cycle process so that the LPT Processor and OTA can effectively manage and track violations and violation notices. The LPT Processor shall track the following information:

798 22.3.1.1 Payments that result in payment in full, partial payment, or over-‐payment.

799 22.3.1.2 Payment reversals due to insufficient funds or chargebacks.800 22.3.1.3 Violations disputed or under administrative review.801 22.3.1.4 Violations dismissed, negotiated, hearing requested or dispute denied.

802 22.4 Vehicle Registration Stop Flags803 22.4.1 The LPT Processor shall develop an interface to the Oklahoma Tax

Commission system to automate the transmission of vehicle registration stop flag placement and removal requests to the Commission.

804 22.4.2 The LPT Processor shall update the stop flag status in real time as the account status changes.

805 22.4.3 The LPT Processor shall never place a stop flag for outstanding amounts consisting only of fees—there must be some toll amount included.

806 22.4.4 The LPT System shall track and report on stop flag activity, including placement requests, removal requests, and payments.

807 22.4.5 The LPT System shall visually indicate to users whether an UPA has amounts due related to a stop flag.









Requirement



808 22.4.6 The LPT System shall clearly display to customer service users the total payment amount required to remove the stop flag, for accounts on which there is an active stop flag.

809 22.5 Collection Agency810 22.5.1 The LPT System shall interface with the collection agency for the

exchange of debt placements and payment data based on an ICD that shall be developed jointly between the collections agency and the LPT Processor.

811 22.5.2 The LPT System shall place unpaid tolls and fees with the collection agency based on the approved escalation process.

812 22.5.3 The LPT System shall only escalate unpaid tolls and fees to the collection agency when are in excess of configurable minimum amounts. The configurable minimum amounts shall be separate for tolls and fees.

813 22.5.4 The LPT System shall reconcile placements and payments with the collection agency.

814 22.5.5 The LPT System shall report to OTA the status of amounts placed with the collection agency based on information provided by the collection agency.

815 22.5.6 The LPT System shall accept, process and track payments made to the LPT Processor for debt placed with the collection agency.

816 22.5.7 The LPT Processor shall update the collection agency with all payments made for transactions in collections.

817 22.5.8 The LPT System shall provide reporting on collection agency related violations and payments as required by OTA.

818 22.5.9 The LPT System shall visually indicate to users whether an UPA has amounts due that have been escalated to the collection agency.

819 22.5.10 The LPT System shall clearly display to customer service users the total outstanding amount that has been escalated to the collection agency.

820 23 Payment Processing821 23.1 General Payment Processing Requirements822 23.1.1 The LPT System shall allow authorized users to process customer

payments according to OTA-‐approved payment processing Policies and Procedures.

823 23.1.2 The LPT Processor shall develop specific Policies and Procedures for processing partial payments.

824 23.1.3 The LPT System shall allow for partial payment of invoices and violation notices.

825 23.1.4 The LPT System shall provide functionality to process partial payments and over-‐payments.









Requirement



826 23.1.5 The LPT System shall apply partial payments to outstanding amounts (all tolls and fees) on a first-‐in, first-‐out basis.

827 23.1.6 The LPT System shall provide an option to allow authorized users to override the first-‐in, first-‐out rule and apply payments to user-‐selected tolls and fees.

828 23.1.7 The LPT System shall apply invoice overpayment amounts to the account as a prepaid balance for use in a subsequent invoice cycle.

829 23.1.8 The LPT System shall apply prepaid balances to outstanding amounts (all tolls and fees) on a first-‐in, first-‐out basis prior to issuing an invoice. This payment shall be reflected on the invoice.

830 23.1.9 The LPT System shall allow authorized users to initiate a refund of any prepaid balance amount in accordance with OTA-‐approved Policies and Procedures (e.g., due to customer request).

831 23.1.10 The LPT System shall have the capability to assess non-‐sufficient funds (NSF) fees for returned checks.

832 24 Account Maintenance and Management 833 24.1 Customer Information and Correspondence834 24.1.1 The LPT System shall support electronically linking documents to

accounts, including both incoming and outgoing correspondence. 835 24.1.2 The LPT System shall ensure all customer correspondence is easily

accessible by the LPT Processor and OTA staff in the performance of customer service tasks.

836 24.1.3 The LPT System shall allow authorized users to enter account notes on any account at any time, and shall store all user-‐entered notes with the account.

837 24.1.4 The LPT System shall allow authorized users to enter an email address on an UPA for customer communications.

838 24.1.5 The LPT System shall allow authorized users to mark an UPA with a valid email address on file as opted-‐in for emailed invoices.

839 24.2 General Account Management840 24.2.1 The LPT System shall allow authorized LPT staff and authorized OTA users

to manage LPT accounts, which shall include the following capabilities:

841 24.2.1.1 View posted Transactions842 24.2.1.2 View payment history843 24.2.1.3 View the account balance844 24.2.1.4 View account notes and contact history845 24.2.1.5 View documents sent to and received from the customer846 24.2.1.6 Attach documents to an account847 24.2.1.7 View and modify customer demographics









Requirement



848 24.2.1.8 View and modify invoice delivery options849 24.2.1.9 View vehicle information850 24.2.1.10 View transaction images851 24.2.1.11 Add and remove credit/debit card and ACH information852 24.2.1.12 Process payments853 24.2.1.13 Dispute tolls and fees854 24.2.2 The LPT System shall not allow modification or removal of the

name/address information returned by an ROV source lookup. 855 24.3 Disputes and Adjustments856 24.3.1 The LPT Processor shall establish and implement processes to receive,

research, document, and resolve all customer disputes. 857 24.3.2 The LPT Processor shall develop Policies and Procedures, subject to OTA

review and approval, for handling all disputes, including conditions under which OTA approval is required.

858 24.3.3 The disposition of all disputes shall be communicated to the customer in the same manner as the dispute was received from the customer (e.g., mail, email, telephone).

859 24.3.4 The LPT Processor shall develop and document, for OTA approval, a dispute escalation process in which certain unresolved disputes shall be escalated to OTA for administrative review.

860 24.3.5 The LPT Processor shall thoroughly research disputes and provide OTA with all relevant documentation related to disputes submitted for administrative review.

861 24.3.6 The LPT System shall allow authorized users to adjust tolls, payments, and fees posted to an account, according to approved Policies and Procedures, and with an appropriate audit trail.

862 24.3.7 The LPT System shall require authorized users to enter account notes for all actions taken in cases of dismissals, disputes, reversals, corrections, and adjustments.

863 24.3.8 The LPT Processor shall schedule hearings (formal process for disputing violation notices) requested by violation notice recipients and prepare hearing evidence packages. Hearings will be conducted by OTA.

864 24.4 Toll/Fee Dismissal865 24.4.1 The LPT System shall support the ability to dismiss one or more

transactions (tolls and/or fees separately).866 24.4.2 The LPT Processor shall develop Policies and Procedures, subject to OTA

approval, for dismissing tolls and/or fees.867 24.5 Transfer of Responsibility (TOR)









Requirement



868 24.5.1 The LPT System shall have the capability and the LPT Processor shall establish and implement procedures for the transfer of responsibility for transactions and related amounts due based on updated vehicle owner information, e.g., rental/leased vehicles or transfer of vehicle ownership.

869 24.5.2 The LPT Processor shall develop Policies and Procedures for obtaining appropriate evidence to support and validate TOR information.

870 24.5.3 If the LPT Processor determines that an invoice or violation notice is eligible for a TOR, according to OTA-‐approved Policies and Procedures, the fees shall be dismissed and the tolls only shall be mailed on a new invoice to the new responsible party’s name and address, restarting the regular escalation process.

871 24.5.4 The LPT System shall retain a record of the transfer on the original account.

872 24.6 UPA Conversion to PIKEPASS873 24.6.1 The LPT Processor shall work with OTA to develop the procedures and

design the functionality required to support conversion of LPT accounts to PIKEPASS accounts. OTA will be responsible for all PIKEPASS development.

874 24.6.2 The LPT System shall allow UPAs to be converted to PIKEPASS accounts by OTA users accessing the LPT System from the OTA CSC only.

875 24.6.3 The LPT System shall retain all LPT account history for the converted UPA, including toll and financial transaction history.

876 24.6.4 The LPT System shall not allow toll or payment transactions to post to any LPT account that has been converted to PIKEPASS. OTA will be responsible for all postings to PIKEPASS accounts established by conversion from LPT accounts.

877 24.6.5 The LPT System shall not allow PIKEPASS conversion of any LPT account with unpaid violations, past-‐due tolls, or fees.

878 24.6.6 The LPT Processor shall require OTA’s authorization to reduce or waive amounts due on an LPT account for the purposes of conversion to a PIKEPASS account.

879 24.6.7 The LPT System shall provide for functionality that flags financial adjustments as due to PIKEPASS conversion / with OTA authorization.

880 24.6.8 Upon successful conversion, the LPT System shall update the LPT account with a status indicating the account was converted to PIKEPASS.

881 25 LPT System Interfaces882 25.1 External Interfaces









Requirement



883 25.1.1 The LPT Processor shall interface with the following entities and shall collaboratively develop, where applicable, an Interface Control Document (ICD) with each entity to establish communication protocol.

884 25.1.1.1 Host system operated by OTA (current ICD is in Appendix E), which includes LPT transactions and images, PIKEPASS account match lookups, Oklahoma, Texas and CVIEW Commercial vehicle License Plate (ROV) lookups, and the HOT list

885 25.1.1.2 ACH and credit/debit card processors 886 25.1.1.3 All required DMVs and/or third party providers who provide vehicle

registration information887 25.1.1.4 Registration stop flags with the Oklahoma Tax Commission888 25.1.1.5 Bank(s) 889 25.1.1.6 Collection agency890 25.1.2 The LPT Processor shall coordinate with third parties and update external

interfaces as needed.891 25.2 Host Interface892 25.2.1 The LPT System shall interface with the OTA Host as detailed in the

Interface Control Document. 893 25.2.2 The LPT Processor shall ensure that all data received via the interface

with the OTA Host is properly accounted for and processed in a timely and accurate manner.

894 25.2.3 The LPT Processor shall coordinate with OTA to setup a Site-‐to-‐Site VPN to secure the data exchanges between the LPT System and OTA Host. It shall be an IPsec or equivalent VPN tunnel with a pre-‐shared key and an agreed upon encryption method.

895 25.3 File Exchanges896 25.3.1 The LPT Processor shall implement system alerts to the LPT Processor

and OTA when any scheduled file exchange does not occur within a configurable amount of time or number of attempts/timeouts.

897 25.3.2 The LPT Processor shall reconcile with the Host at the file level, for all files received.

898 25.3.3 The LPT Processor shall reconcile transaction files with the Host at the individual transaction level, for each transaction record in the file received.

899 25.4 Transaction Reconciliation900 25.4.1 The LPT Processor shall reconcile transaction statuses to OTA that

indicate the current processing status of each transaction received from the Host.

901 25.4.2 The LPT Processor shall prepare and send reconciliation files on a configurable basis.









Requirement



902 25.4.3 The LPT Processor shall provide an updated reconciliation status for a given transaction any time there is a change in its processing status from the last update sent to OTA.

903 25.4.4 The LPT Processor shall use reconciliation codes to indicate the transaction’s current processing status.

904 25.4.5 The LPT Processor shall finalize the list of reconciliation codes and associated processing statuses with OTA during the design phase.

905 25.4.6 The LPT Processor shall update the OTA Host to LPT System ICD with the final list of reconciliation codes. Following are examples of the types of statuses for which the LPT Processor shall provide reconciliation codes.-‐ Interim – Transaction received by the License Plate Tolling Processor -‐ Rejected – Duplicate transaction-‐ Rejected – Rejected by DMV/ROV source-‐ Rejected – No DMV reciprocity-‐ Dismissed – OTA request-‐ Interim – In image review-‐ Interim – Invoiced-‐ Interim – Past due invoice-‐ Interim – Transfer of Responsibility (TOR)-‐ Final – Dismissed at PIKEPASS request-‐ Final – Dismissed by LPT Processor-‐ Final – Dismissed for PIKEPASS conversion -‐ Final – Paid Invoice

906 25.5 PIKEPASS Account Match Lookups907 25.5.1 The LPT System shall utilize the PIKEPASS data provided by OTA to

compare License Plate number and jurisdiction against the PIKEPASS customer database.

908 25.5.2 The LPT System shall send a file, in an agreed upon format using an interface or file transfer method, the list of Toll Transaction IDs and Image IDs that were found to be PIKEPASS customer transactions.

909 25.5.3 The LPT System shall request an acknowledgement of receipt and then process the stored transactions and images it sent in the file as dismissed as PIKEPASS or equivalent code.

910 25.5.4 The LPT System shall track the number of PIKEPASS transactions it finds and provide it in the reconciliation report via the web service with the OTA Host.

911 25.6 Oklahoma License Plate Lookups912 25.6.1 The LPT System shall query the OTA-‐provided database of OK License

Plate numbers to obtain ROV information for processing tolls.









Requirement



913 25.6.2 The LPT Processor shall adhere to OTA data retention and security standards to ensure the PII data received from the OK License Plate database is secure and not breached.

914 25.7 Texas License Plate Lookups 915 25.7.1 The LPT System shall query the OTA-‐provided database of TX License

Plate numbers to obtain ROV information for processing tolls. 916 25.7.2 The LPT Processor shall adhere to OTA data retention and security

standards to ensure the PII data received from the TX License Plate database is secure and not breached.

917 25.8 CVIEW License Plate Lookups 918 25.8.1 OTA will provide the LPT Processor with access to a read-‐only database of

the CVIEW commercial License Plates and the registered owner of the vehicle (ROV) information.

919 25.8.2 The LPT System shall query the OTA-‐provided database of CVIEW commercial License Plate numbers to obtain ROV information for processing tolls.

920 25.8.3 The LPT Processor shall adhere to OTA data retention and security standards to ensure the PII data received from the CVIEW commercial License Plate database is secure and not breached.

921 25.9 Hot Lists922 25.9.1 The LPT System shall process the Hot List and notify OTA via the web

service when License Plate matches are found. 923 25.10 Oklahoma Tax Commission 924 25.10.1 The LPT Processor shall place vehicle registration stop flags for Oklahoma

license plates with the Oklahoma Tax Commission.925 25.10.2 The LPT Processor shall coordinate with the Oklahoma Tax Commission

to develop an ICD, which shall define an interface to send registration stop flags to the Oklahoma Tax Commission system.

926 25.10.3 The LPT System shall request acknowledgement via the interface that the stop flag has been applied.

927 25.10.4 The LPT System shall notify OTA via the daily reconciliation how many LPT customers have stop flags applied.

928 25.10.5 The LPT System to Oklahoma Tax Commission interface shall also have the ability to release stop flags, and shall subsequently also notify OTA via the daily report of the number of stop flag releases.

929 25.10.7 The LPT Processor shall remove the stop flag, update the account and reconcile to OTA when a payment has been resolved.

930 25.11 Third Party Interfaces









Requirement



931 25.11.1 The LPT Processor shall coordinate with any third party vendor it uses for LPT processing to develop an ICD that defines the interface between the third party and the LPT System.

932 25.11.2 All ICDs for third party interfaces, including those below, shall follow the same framework as the OTA Host to LPT System ICD in Appendix E.

933 25.11.2.1 ACH and credit/debit card processors 934 25.11.2.2 Bank(s) 935 25.11.2.3 Collection agency936 26 Mail Processing937 26.1 General Mail Processing Requirements938 26.1.1 The LPT Processor shall generate, distribute and track all printed

customer correspondence, including materials in the form of letters, notices, invoices and general correspondence.

939 26.1.2 The LPT Processor shall establish and administer all postal service relationships. The actual cost of postage for outgoing mail shall be a direct pass through cost to OTA with no mark-‐up.

940 26.1.3 The LPT Processor shall utilize the extended ZIP+4 Codes in all mailing where available.

941 26.1.4 The LPT Processor shall track and report on all incoming and outgoing correspondence by type.

942 26.1.5 The LPT Processor shall implement a process to manage, research, correct, and minimize mail returned as undeliverable.

943 26.1.6 The LPT Processor shall track and report on mail returned as undeliverable.

944 26.2 Incoming Mail Processing945 26.2.1 The LPT Processor shall establish and implement procedures to provide

effective and efficient handling of all incoming mail, including procedures for tracking customer correspondence.

946 26.2.2 The LPT Processor shall accurately timestamp all incoming correspondence for quality assurance and audit purposes.

947 26.2.3 The LPT Processor shall provide an appropriate response to all customer inquiries received by mail, according to OTA-‐approved Policies and Procedures.

948 26.2.4 The LPT Processor shall scan all incoming mail. 949 26.2.5 The LPT System shall associate scanned mail related to an LPT account

with the account to allow users to view a digital image of the document. 950 26.2.6 The LPT Processor shall store all scanned mail that is not associated to an

LPT account in an electronic file. 951 26.3 Outgoing Mail Processing









Requirement



952 26.3.1 The LPT Processor shall establish and implement a process to provide the timely, efficient and accurate handling of all outgoing mail.

953 26.3.2 The LPT Processor shall track the date and time that all outgoing correspondence is mailed for quality assurance and audit purposes.

954 26.3.3 The LPT Processor shall send all paper customer correspondence via first class mail or better, unless specifically directed by OTA to do otherwise.

955 26.3.4 The LPT Processor shall send all 2nd violation notices via Certified Mail.956 26.3.5 The LPT Processor shall employ bulk mail rates and other mailing

economies, where available, including the capacity for pre-‐sorting mail by Zip Code to ensure the most cost effective postage rates are obtained.

957 26.3.6 The LPT Processor shall have full responsibility over any mail house services that it may choose to outsource.

958 26.3.7 The LPT Processor shall establish and implement quality assurance procedures that include the monitoring, spot checking and tracking of all outgoing mail.

959 26.3.8 The LPT Processor shall generate configurable form letters and individual situational customer correspondence as appropriate.

960 26.3.9 The LPT Processor shall utilize skip tracing and develop procedures to attempt to obtain an address for all returned mail.

961 26.3.10 For invoices and violation notices returned by the US Postal Service (USPS) with a forwarding address, the LPT Processor shall reissue the invoice or violation notice to the forwarding address provided by the USPS.

962 26.3.11 The LPT Processor shall utilize a process for address standardization.963 26.3.12 The LPT Processor shall utilize the National Change of Address (NCOA)

service.964 26.3.13 If the NCOA returns an updated address, the LPT Processor shall reissue

the invoice or violation notice to the updated address.









Requirement



965 26.3.14 The LPT Processor shall design all customer correspondence with OTA during the design phase. A sample list of the types of customer correspondence envisioned for the LPT program is included below: -‐ Welcome Letter-‐ Invoices-‐ Violation Notices-‐ Returned Check Letter-‐ ACH Reject Letter-‐ Registration Hold Letter-‐ Sent to Collections Agency Letter-‐ Dispute Resolution-‐ Returned Email -‐ Refunds-‐ Other Inquiry Response

966 27 Customer Communications & Materials967 27.1 Customer Communications968 27.1.1 The LPT Processor shall be responsible for all aspects of communication

with LPT customers, including communications via telephone, mail, email, web, and fax.

969 27.1.2 The LPT Processor shall record and maintain an historical record of all customer contacts in the account.

970 27.1.3 The LPT Processor shall design, produce, inventory, and distribute all customer communications and correspondence as approved by OTA.

971 27.1.4 The LPT Processor shall answer inquiries from the general public provided the subject is consistent with general information related to the LPT locations and LPT customer service.

972 27.1.5 The LPT Processor shall not initiate promotional or other unsolicited informational communication with unregistered LPT customers.

973 27.2 Email 974 27.2.1 The LPT Processor shall have the capability to receive customer inquiries

and requests via email and respond to customer inquiries and requests via email.

975 27.2.2 The LPT Processor shall send all customer correspondence via email, when provided by and indicated as preferred by the customer, except where hard copies are required.

976 27.2.3 The LPT Processor shall establish, implement and maintain a process to allow customers to opt-‐in to receive messages via email.

977 27.2.4 The LPT Processor shall use industry best practices for handling undeliverable email messages.









Requirement



978 27.2.5 The LPT Processor shall develop the format and content of all email messages during the design phase and shall require OTA approval of any changes thereafter.

979 27.3 Social Media980 27.3.1 The LPT Processor shall work with the OTA’s Director of Communications

and/or his designee for implementing and maintaining public communications via social media.

981 27.3.2 The LPT Processor shall obtain OTA authorization and approval of any customer interaction via social media.

982 27.3.3 The LPT Processor shall work with OTA to identify and disseminate messages and information about the License Plate Tolling program (e.g., monitor social media, notify OTA of issues, and provide recommended responses and feedback when requested by OTA).

983 27.4 IVR System 984 27.4.1 The LPT Processor shall establish, operate and maintain an interactive

voice response (IVR) system. 985 27.4.2 The LPT Processor shall utilize IVR system components, including ancillary

equipment and software, which are dedicated to the LPT System for use for the License Plate Tolling program.

986 27.4.3 The LPT IVR system (“LPT IVR”) or subcomponents and software shall not be shared with other co-‐located/supported LPT Processor clients.

987 27.4.4 The LPT Processor shall provide a toll-‐free telephone number for the LPT IVR.

988 27.4.5 The LPT IVR shall route calls and accept payments via menu selections and user input.

989 27.4.6 The LPT IVR shall provide customers with the ability to hear amounts due and make payments (via debit/credit cards or ACH) 24 hours per day, 7 days per week.

990 27.4.7 The LPT IVR shall require appropriate authentication (e.g., an invoice number and access PIN) prior to providing any account specific information.

991 27.4.8 The LPT IVR shall provide users with an option to be transferred to a CSR during operating hours.

992 27.4.9 The LPT IVR shall provide customers with the option to be transferred to a Spanish speaking CSR during operating hours.

993 27.4.10 The LPT IVR shall provide callers who request to be transferred to a CSR with the estimated waiting time to speak to a CSR upon entering the CSR queue and every 60 seconds during their time in queue.

994 27.4.11 The LPT IVR shall be fully integrated with the functional LPT System.









Requirement



995 27.4.12 During non-‐business hours, the LPT IVR shall announce a message informing callers that the live call center is now closed but customers can make payments via the IVR system and website.

996 27.4.13 The LPT IVR system shall interact with the LPT System database in real time to retrieve account information.

997 27.4.14 The IVR system shall utilize a single recorded voice talent and have consistency in volume and intonation, except in certain time sensitive situations as directed and approved by OTA.

998 27.4.15 The LPT Processor shall obtain OTA approval of the IVR system voice talent and script.

999 27.4.16 The LPT Processor shall have the ability to remotely make short term, time sensitive changes to the IVR system.

1000 27.4.17 The LPT Processor shall make necessary changes to the IVR script, messages, and menu options at no additional cost to and only upon approval by OTA.

1001 27.4.18 The LPT Processor shall ensure that the IVR system is ADA compliant throughout the Term.

1002 27.5 Call Center1003 27.5.1 The LPT Processor shall provide call center staff that are dedicated solely

to the OTA License Plate Tolling program.1004 27.5.2 The LPT Processor shall provide all hardware and software for processing

incoming customer calls.1005 27.5.3 The LPT Processor shall have sufficient staff in place during the defined

operating hours to handle all inbound callers who wish to speak to a CSR within the time parameters specified in the Performance Standards.

1006 27.5.4 The LPT Processor shall establish and document Policies and Procedures, subject to OTA review and approval, for the escalation of calls and issues to LPT Processor supervisory and management staff, as well as to OTA staff.

1007 27.5.5 The LPT Processor shall track and resolve all escalated issues. 1008 27.5.6 The LPT Processor shall record detailed account notes related to each

call. 1009 27.5.7 The LPT System shall document, track and report all IVR system and CSR

calls, separately, by specific reason for the call (e.g., dispute, payment).1010 27.5.8 The LPT Processor shall record the reason(s) for each call via call reason

codes that will be established by the LPT Processor and approved by OTA during design.

1011 27.5.9 The LPT System shall provide for input of multiple codes in cases where more than one reason/type code applies to the call.









Requirement



1012 27.5.10 The LPT System shall provide for, and the LPT Processor shall establish and implement processes for, supervisory monitoring of both live and recorded CSR calls for accuracy, efficiency, professionalism and courteous service.

1013 27.5.11 The LPT Processor shall develop a form to record CSR monitoring activity and shall submit the form to OTA for approval. The LPT Processor shall keep completed CSR monitoring forms on file for a year and submit a monthly summary to OTA.

1014 27.5.12 The LPT Processor shall provide OTA with automated capability to monitor any live customer calls from offsite, at any time without prior notification to the LPT Processor or to the CSR being monitored.

1015 27.5.13 The LPT Processor shall ensure that the phone system announces on all calls that calls may be monitored (e.g., ‘calls may be monitored for quality assurance purposes’).

1016 27.5.14 The LPT Processor shall ensure that the phone system is ADA compliant throughout the Term.

1017 27.5.15 Once a customer call is answered by a CSR, the call shall not be immediately placed on hold to answer another call.

1018 27.5.16 Call center staff shall respond to customer non-‐LPT related calls (e.g., OTA policies, turnpike operations, PIKEPASS accounts, interoperability, points of customer contact) by providing information in accordance with specific scripts approved by OTA or refer caller to PIKEPASS CSC or website.

1019 28 Website1020 28.1 Website Requirements1021 28.1.1 The LPT Processor shall design, develop, implement, host, and maintain

an intuitive, user-‐friendly, and interactive customer website, including the website domain.

1022 28.1.2 The LPT Processor shall provide OTA with a link to the LPT website that can be used on the OTA PIKEPASS website to direct customers to the LPT Processor website.

1023 28.1.3 The LPT Processor shall prominently display a link to PIKEPASS.com for questions and issues not related to License Plate Tolling.

1024 28.1.4 The LPT System database interface to the LPT website shall facilitate the automatic electronic exchange of all required account information supporting all required functionality.

1025 28.1.5 The LPT Processor shall design the website using industry best practices for easy updating and workflow changes and include a content management module that will allow authorized OTA staff to update content without the need for extensive LPT Processor assistance.









Requirement



1026 28.1.6 The LPT website shall be optimized for, and function properly, on Internet Explorer, Safari, Firefox and Chrome, as well as on multiple platforms including personal computers, mobile devices and tablet devices.

1027 28.1.7 The LPT website shall be secure and require appropriate customer authentication for all account-‐specific pages.

1028 28.1.8 The LPT Processor shall define and develop the specific look, functionality, and navigation of the website with OTA during the design phase.

1029 28.1.9 The LPT Processor shall ensure that the website is ADA compliant throughout the Term.

1030 28.2 Website Account Management1031 28.2.1 The website shall provide customer access to account information

through a secure login.1032 28.2.2 Access to customer account data shall require login with an invoice

number and license plate number/state, or an invoice number and access PIN.

1033 28.2.3 All customer account activity made via the website shall be immediately reflected in the database and on the customer account screens.

1034 28.3 Website Services1035 28.3.1 The LPT Processor website shall provide customers with the following

functionality:1036 28.3.1.1 View current and past invoices1037 28.3.1.2 View current and past violations1038 28.3.1.3 View current and past images1039 28.3.1.4 Pay invoice via credit card, debit card, or ACH1040 28.3.1.5 Pay violations via credit card, debit card, or ACH1041 28.3.1.6 Associate an email with the account1042 28.3.1.7 Opt-‐in/out of email invoices1043 28.3.1.8 Opt-‐in/out of email correspondence1044 28.3.1.9 Dispute process1045 28.3.2 The LPT Processor shall provide a “Contact Us” feature and various

methods to communicate with the LPT Processor via the website, using email or HTML forms.

1046 28.3.3 The LPT System shall acknowledge customer inquiries received via the website via an automated email receipt confirmation to the customer.

1047 28.3.4 The website shall provide static informational pages, including the following:

1048 28.3.4.1 A description of the LPT program 1049 28.3.4.2 Invoice escalation process including violations, collections and fees









Requirement



1050 28.3.4.3 Vehicle registration stop flag process1051 28.3.4.4 Payment information1052 28.3.4.5 How to sign up for a PIKEPASS account1053 28.3.4.6 Help and frequently asked question1054 28.3.4.7 Privacy Policy1055 28.3.4.8 Downloadable forms and customer guides1056 28.3.4.9 Links to other sites to be determined by OTA1057 28.3.5 The LPT Processor shall perform all website maintenance and content

updates. 1058 28.4 Website Security1059 28.4.1 The LPT Processor shall institute security measures to prevent

unauthorized access to the LPT System, and maintain the confidentiality and security of all customer data subject to applicable federal, state and local laws and applicable financial and banking policies, including Payment Card Industry Data Security Standards (PCI DSS).

1060 28.4.2 The LPT Processor shall maintain proper PCI DSS compliance on the website used for account management throughout the Term.

1061 28.4.3 The LPT Processor shall be responsible for all costs related to maintaining compliance with PCI DSS and any related updates.

1062 28.4.4 The website shall incorporate a firewall, or security appliance, with security functions to prevent unauthorized access to any parts of the LPT System.

1063 28.4.5 The LPT Processor shall use appropriate protocols to ensure secure data transmission from/to the user’s browser.

1064 28.4.6 The website shall utilize secure connection with all confidential communications encrypted Transport Layer Security (TLS) protocol.

1065 28.4.7 LPT Processor shall provide, operate and maintain the website in a manner that adheres to the current industry best practices for website security.

1066 28.4.8 The OTA privacy policy shall be accessible via hyperlink on the footer of every page.

1067 28.4.9 The LPT Processor shall acquire the website security certificate and maintain it in full force and effect throughout the Term.

1068 29 Payment Processing1069 29.1 General Payment Processing Requirements1070 29.1.1 The LPT Processor shall securely process all payments received. 1071 29.1.2 The LPT Processor shall accurately track the chain of custody of all

payments.1072 29.1.3 The LPT Processor shall apply all payments to the correct accounts in the

LPT System.









Requirement



1073 29.1.4 The LPT Processor shall establish and implement daily, weekly and monthly reconciliation processes, audit trails and controls to safeguard all funds received.

1074 29.1.5 The LPT Processor shall handle payment adjustments, reversals, refunds, NSF checks, partial payments, overpayments, split payments, and unidentified payments.

1075 29.1.6 The LPT Processor shall establish and implement processes for handling of all payments, including partial payments and overpayments.

1076 29.1.7 The LPT System shall apply payments received without specific customer direction to outstanding customer balances based on OTA approved Policies and Procedures.

1077 29.1.8 The LPT System shall apply partial payments to the oldest tolls/fees first (first-‐in, first-‐out) by default.

1078 29.1.9 The LPT System shall provide functionality for users to manually apply partial payments to specific tolls/fees (not first-‐in, first-‐out) in accordance with customer instructions or OTA direction.

1079 29.1.10 The LPT Processor shall process, resolve, reconcile, and report unidentified payments (payments not accompanied by information to allow matching to an account).

1080 29.1.11 The LPT Processor shall handle unidentified payments that cannot be resolved in accordance with applicable Oklahoma State escheatment laws.

1081 29.1.12 The LPT Processor shall gather and package all data related to unidentified payments as directed by OTA.

1082 29.1.13 The LPT Processor shall verify that checks are signed and completed properly, and that credit/debit card numbers and signatures are completed properly.

1083 29.1.14 The LPT Processor shall track, handle and report on incomplete payments such as unsigned checks and incomplete credit/debit card numbers.

1084 29.1.15 The LPT Processor shall scan all customer payment correspondence, including the front and back of all checks.

1085 29.1.16 The LPT System shall associate and store images of scanned payment correspondence, including checks, with the appropriate account.

1086 29.1.17 The LPT Processor shall track and report on all payments by location, by user, by posting date, and by payment method.

1087 29.1.18 The LPT Processor shall reconcile all payments posted to bank deposits and credit/debit card/ACH processing receipts on a daily basis.

1088 29.1.19 The LPT Processor shall maintain a record of any discrepancies with bank deposits and report them immediately to OTA.









Requirement



1089 29.1.20 The LPT Processor shall ensure that all payments are deposited into the correct bank account as designated by OTA.

1090 29.1.21 The LPT Processor shall reconcile all cash and check payments received from all sources to daily bank deposits.

1091 29.2 Credit/Debit Card and ACH Processing1092 29.2.1 The LPT Processor shall be responsible for all aspects of credit/debit card

and ACH processing. 1093 29.2.2 The LPT Processor shall utilize the OTA credit/debit card and ACH service

providers and employ methods and practices that provide OTA with the lowest possible credit/debit card and ACH fees. OTA will pay credit/debit card and ACH processing fees directly to the processors.

1094 29.2.3 The LPT Processor shall accept payments via the following credit/debit cards, at a minimum: Visa, MasterCard, American Express and Discover.

1095 29.2.4 The LPT Processor shall establish and maintain an interface with the credit/debit card/ACH processors.

1096 29.2.5 The LPT Processor shall resolve credit/debit card and ACH transaction processing issues with the processors.

1097 29.2.6 The LPT Processor shall monitor and immediately report any transaction processing interruptions to OTA.

1098 29.2.7 The LPT Processor shall reconcile LPT System credit/debit card transactions to information provided by the credit/debit card processor and the bank.

1099 29.2.8 The LPT Processor shall ensure that the credit/debit card processor deposits all credit/debit card and ACH payments directly into appropriate bank accounts via electronic transfer.

1100 29.2.9 The LPT Processor shall comply with the security and reporting standards of the credit/debit card issuer and processor.

1101 29.2.10 The LPT Processor shall work with the credit/debit card processor in the review and resolution of customer credit/debit card chargebacks.

1102 29.2.11 The LPT System shall flag payments that are in the chargeback review process and indicate resolution of the review in the account.

1103 29.2.12 The LPT Processor shall make appropriate account adjustments in response to payment chargebacks.

1104 29.2.13 The LPT Processor shall only store and transmit encrypted credit/debit card numbers and shall ensure security over credit/debit card information in compliance with the most current PCI standards.

1105 29.2.14 The LPT Processor shall adhere to all requirements of the credit/debit card processor, the bank and PCI.









Requirement



1106 29.2.15 The LPT Processor shall review industry standards for enhancements and updates to the credit/debit card and ACH processing platform, at least annually, to ensure that the processing methods and systems remain current with the latest technology, security, and processing rules. The LPT Processor shall provide OTA with the results of such reviews.

1107 29.2.16 In the event of an authorization decline from the processors for reasons other than a lost or stolen credit/debit card, the LPT Processor shall make a configurable number of authorization requests over a configurable period of time.

1108 29.2.17 The LPT Processor shall ensure that all credit/debit card and ACH charges have been posted properly to customer accounts, transmitted to credit/debit card processor for payment, and that payments are received from the processor.

1109 29.2.18 The LPT Processor shall reconcile all credit/debit card transactions with requests sent to the credit/debit card processor and with receipt of funds transferred by the processor.

1110 29.2.19 The LPT Processor shall process all credit/debit card and ACH transactions on a daily basis.

1111 29.2.20 The LPT System shall track and record all activity related to credit/debit card and ACH payments, payment attempts, reversals and refunds in a customer's account within the LPT System in a sortable and searchable fashion.

1112 29.2.21 The LPT System shall have a configurable limit to the number of customer initiated credit/debit card payments within a configurable period of time.

1113 29.3 Cash and Checks Processing1114 29.3.1 The LPT Processor shall establish and implement procedures to accept

and process all cash and checks received via mail.1115 29.3.2 The LPT Processor shall establish and implement procedures to accept

and process payments received by PIKEPASS for LPT payments.1116 29.3.3 The LPT Processor shall establish and utilize electronic check processing. 1117 29.3.4 The LPT Processor shall post all cash and checks received to the

customer's account and process them for payment by the bank.1118 29.3.5 The LPT Processor shall provide an armored courier service for the

transfer of funds to the designated bank. 1119 29.3.6 The LPT Processor shall properly safeguard all cash and checks at all

times and shall maintain records of the chain of custody of all funds.









Requirement



1120 29.3.7 The LPT System shall reverse any checks that are not honored, record them in the account and assess the appropriate non-‐sufficient funds (NSF) fee.

1121 29.3.8 The LPT Processor shall establish and implement a process for including NSF check amounts due and related fees on invoices and violation notices.

1122 29.3.9 The LPT System shall track the number of NSF checks received by an individual customer and have the ability to reject check payments by that customer after a configurable number of NSF checks have been received in a configurable period of time.

1123 29.3.10 The LPT Processor shall account for and reconcile each payment received by payment type, by payment source, by CSR or payment processor, on a daily basis.

1124 29.3.11 The LPT Processor shall utilize and support Positive Pay Processing for all refund checks issued. This includes the generation and issuance of Positive Pay files to the bank and the monitoring and handling of all related issues and exceptions.

1125 29.3.12 The LPT Processor shall advise OTA of any issues related to Positive Pay on a daily basis.

1126 29.4 Refunds 1127 29.4.1 The LPT Processor shall develop and implement OTA-‐approved Policies

and Procedures to evaluate refund requests and process refunds for approved requests, including for eligible customer overpayments and error corrections. The methodology for refunds shall be finalized during design.

1128 29.4.2 The LPT Processor shall designate and identify staff with the authority to process refunds.

1129 29.4.3 The LPT Processor shall document all refunds in the LPT System customer account.

1130 29.4.4 The LPT System shall track and report on refund activity on a monthly basis. This shall include refund information related to refund requests, issued refunds, refund method, accounts, dates, times, customer name and address data, approval level, name or employee ID number of individual processing and approving the refund, pending refunds, and the reason for approval or denial of the refund request.

1131 29.4.5 The LPT Processor shall handle refunds that are returned by the post office as undeliverable in accordance with applicable Oklahoma State escheatment laws. The LPT Processor shall gather and package all data as directed by OTA.









Requirement



1132 29.4.6 The LPT Processor shall maintain PCI compliance regarding all credit/debit card refunds.

1133 30 Cash Payment Network1134 30.1 General Cash Payment Location Requirements1135 30.1.1 The LPT Processor shall provide a Cash Payment Network (CPN) to accept

customer funds at merchant locations.1136 30.1.2 The LPT Processor shall ensure the CPN provider is licensed to operate as

a money services business in Oklahoma and all states in which the CPN is offering the OTA LPT program payments.

1137 30.1.3 The LPT Processor shall guarantee to OTA all funds for all transactions processed at participating CPN locations.

1138 30.1.4 The LPT Processor shall be responsible for all hardware, software and telecommunications costs incurred by the LPT Processor and its provider(s) associated with the provision of CPN transaction services.

1139 30.1.5 The CPN interface shall not degrade the LPT System’s performance, reliability, or availability.

1140 30.1.6 The LPT Processor shall document measures being taken to ensure secure transfer of information between the CPN and the LPT Processor and its adherence to PCI compliance requirements.

1141 30.1.7 The LPT Processor shall provide at least 48 hours advanced notice to OTA when the CPN is planned to be unavailable to OTA customers for more than 60 minutes.

1142 30.1.8 The LPT Processor shall provide OTA with immediate notification anytime the CPN becomes unavailable to OTA customers for unplanned periods of longer than 60 minutes.

1143 30.1.9 The LPT Processor shall ensure proper notification is displayed at the point of sale describing the CPN outage whenever the CPN is unavailable to OTA customers.

1144 30.1.10 All payment processing requirements of this Scope of Work apply to payments made via the CPN.

1145 30.2 CPN Payments1146 30.2.1 The LPT Processor shall implement a CPN that accommodates invoice

and violation payment activities at each participating merchant location.1147 30.2.2 The CPN shall provide the ability for customers to view their outstanding

amount due at no cost. 1148 30.2.3 The CPN shall provide for configurable minimum and maximum payment

amounts.1149 30.2.4 The CPN shall require either a scanned document barcode or two data

entries for customer access validation as approved by OTA during design.









Requirement



1150 30.2.5 If the customer enters or scans a paid or escalated invoice barcode, the CPN shall retrieve and display the most recent total outstanding amount due on the account and allow the customer to make a payment to the account.

1151 30.3 CPN Transaction Fees1152 30.3.1 CPN transaction fees, if any, shall be prominently displayed at the point

of sale and available to the customer prior to completing the transaction.

1153 30.3.2 CPN transaction fees charged to customers shall be approved by OTA.1154 30.3.3 CPN transaction fees shall be posted on the LPT/CPN webpage and

printed on all transaction receipts.1155 30.4 CPN Receipts1156 30.4.1 The CPN shall generate, OTA approved, printed receipts for all payments

and shall advise customers to retain the receipt for their records as proof of payment.

1157 30.4.2 The CPN shall ensure all receipts include complete transaction information, which may include any or all of the following (to be finalized during design): -‐ A CPN Reference ID number that uniquely identifies the payment and is searchable in the LPT System-‐ Type of document (invoice or violation) and document ID for which the payment was initiated-‐ Account number to which the payment was made-‐ Total amount paid, with a breakdown of any fees-‐ Amount due before payment-‐ Amount due on the account, if any, after payment-‐ Date and local time of the payment-‐ Merchant location identifier-‐ Name and contact details of the merchant-‐ LPT Processor phone number and website address-‐ Configurable message lines, for text to be provided and updated by OTA as frequently as once per month

1158 30.5 LPT and CPN Interface1159 30.5.1 The LPT Processor shall develop an interface to the CPN that implements

all data exchanges necessary to meet the requirements contained herein.

1160 30.5.2 The CPN System shall provide customers with the same up-‐to-‐date account balance information that would be available via the LPT Website or by calling the LPT Processor.









Requirement



1161 30.5.3 When a CPN transaction is complete at a merchant location, the LPT System shall immediately reflect the payment and update any remaining amount due on the account.

1162 30.6 CPN Merchant Locations1163 30.6.1 The LPT Processor shall require all publicly located CPN merchant

locations to accept cash. Locations may also accept other forms of payment (credit/debit card, check).

1164 30.6.2 Each merchant location proposed for participation in the CPN by the LPT Processor shall require OTA approval prior to rollout or marketing of that location for OTA payments.

1165 30.6.3 The LPT Processor shall ensure that CPN is available at merchant locations within a mutually agreed to area surrounding OTA tolling facilities.

1166 30.6.4 The LPT Processor shall provide OTA with a plan detailing the identification, recruitment, sign-‐on, training, and rollout of CPN merchant locations.

1167 30.6.5 CPN services may be performed by point of sale (POS), kiosk, or other systems that shall be pre-‐approved by OTA.

1168 30.6.6 The LPT Processor shall work with OTA to design a customer-‐friendly, intuitive user interface, with the final design requiring OTA approval prior to rollout.

1169 30.6.7 The CPN user interface shall display a response to customer data requests in near real-‐time.

1170 30.6.8 The LPT Processor shall monitor the quality of merchant services and discontinue a merchant location if it is determined that standards are not met or at the request of OTA (within one business day of the request).

1171 30.7 CPN Merchant Locator1172 30.7.1 The LPT Processor shall develop and maintain a publicly available

webpage for locating participating merchants that offer LPT CPN services (the Merchant Locator).

1173 30.7.2 The LPT Processor’s CPN Merchant Locator shall provide a mobile-‐friendly website.

1174 30.7.3 The LPT Processor shall ensure merchants that are no longer participating or do not meet requirements for the CPN are removed from the Merchant Locator within 1 business day of the removal of functionality, determination of failure to meet standards, or OTA request.









Requirement



1175 30.7.4 The LPT Processor’s CPN Merchant Locator shall allow users to retrieve a list of a configurable number of the CPN merchant locations closest to an address or Zip Code input by the user.

1176 30.7.5 The LPT Processor’s CPN Merchant Locator shall list the CPN locations returned by the search—with street address, hours of operation, and phone number—and display them on a map view to the user.

1177 30.7.6 The LPT Processor’s CPN Merchant Locator shall include the option to display a static map view of all participating CPN locations, without entering any search criteria.

1178 30.7.7 The CPN Merchant Locator shall be available through the LPT Processor’s customer website.

1179 30.8 CPN Reports1180 30.8.1 The LPT Processor shall provide daily, monthly and annual detailed CPN

transaction reporting to include the following details for every transaction completed in the reporting period:

1181 30.8.1.1 Payment type (invoice or violation, based on input account/document ID)

1182 30.8.1.2 Payment date and time1183 30.8.1.3 Account number1184 30.8.1.4 Invoice/violation number1185 30.8.1.5 Payment amount1186 30.8.1.6 Transaction fee amount1187 30.8.1.7 Merchant location ID1188 30.8.1.8 Merchant zip code1189 30.8.2 The LPT Processor shall provide daily, monthly, and annual CPN reporting

to include the following summary information for all transactions completed in the reporting period:

1190 30.8.2.1 Number of payments by type1191 30.8.2.2 Total payment amount by payment type1192 30.8.2.3 Total fees by payment type1193 30.8.2.4 Total payments by merchant location ID1194 30.8.2.5 Total payments by merchant location zip code1195 30.8.2.6 Total payments by merchant location county1196 30.8.3 The LPT Processor shall provide a monthly report with CPN system

availability by location.1197 30.9 CPN Customer Service Requirements1198 30.9.1 The CPN and the LPT Processor shall clearly define and communicate to

customers the appropriate point of contact for customer service related to CPN locations and transactions, in accordance with OTA-‐approved Policies and Procedures.









Requirement



1199 30.9.2 The LPT Processor shall train its staff to answer customer questions regarding CPN locations, procedures for using the CPN, and CPN usage and payment history.

1200 30.9.3 The System shall flag financial transactions that occur at a CPN so that LPT Processor staff can identify them as such for research and customer service purposes.

1201 30.9.4 The LPT Processor shall ensure each merchant location prominently displays a phone number for help with using the CPN.

1202 30.9.5 The LPT Processor shall provide Policies and Procedures for researching and addressing CPN customer complaints and this shall be provided to and approved by OTA prior to CPN rollout.

1203 30.9.6 The LPT Processor shall ensure that a customer call center is available to address customer issues regarding the CPN. OTA strongly prefers the call center be available 24/7, however at a minimum, the CPN call center shall be available during the same hours that the LPT Processor call center is available.

1204 31 Financial Responsibilities 1205 31.1 General Financial Responsibilities Requirements1206 31.1.1 The LPT Processor shall establish and perform all financial functions

necessary for the LPT operation, including accepting and processing payments, interfacing with banking institutions and credit/debit card and ACH processors, managing bank transactions and all reconciliations, and implementing audits and internal control procedures.

1207 31.1.2 The LPT System shall have the ability to identify, segregate and accumulate revenue and accounts receivable between locations and cost centers as determined by OTA.

1208 31.1.3 The LPT System shall provide an audit trail for each financial transaction.1209 31.1.4 The LPT Processor shall use proper cut-‐off procedures for daily, monthly,

and year-‐end close. 1210 31.1.5 The LPT Processor shall follow OTA’s daily, monthly, and year-‐end closing

schedule and produce timely reports to allow OTA to meet its schedule.

1211 31.1.6 The LPT System shall identify and report on transactions at various stages of their escalation process (e.g., outstanding violations and invoices).

1212 31.1.7 The LPT System shall make a configurable bad debt calculation to each stage of the escalation process. This debt calculation shall include a configurable threshold for the amount outstanding.

1213 31.1.8 The LPT System shall report on and track all write-‐offs.1214 31.2 Financial Reconciliation









Requirement



1215 31.2.1 The LPT Processor shall reconcile all financial activity on a daily and monthly basis.

1216 31.2.2 The LPT Processor shall provide the results of all reconciliations including reconciliation spreadsheets and reports on resolution of variances to OTA in a timely manner.

1217 31.2.3 The LPT Processor shall provide any documentation needed to support reconciliations upon OTA request.

1218 31.2.4 The LPT Processor shall resolve all variances through adjustments, reversals or research.

1219 31.2.5 The LPT System shall allow users to record results of research, including comments and scanned documents or images, and associate the record with the variance.

1220 31.2.6 As part of the report on resolution of variances, the LPT Processor shall provide a list of action items with a schedule for items that require extended research, system fixes, or other extended time periods for resolution.

1221 31.2.7 The LPT System shall support the reconciliation processes. At a minimum, the LPT System shall do the following:

1222 31.2.7.1 Exception identification1223 31.2.7.2 Automated reconciliation procedures1224 31.2.7.3 Drill down from summary level to the transaction or activity level1225 31.2.8 The LPT System shall provide automated reconciliations for all

transactions.1226 31.2.9 The LPT Processor shall reconcile all payments received by the LPT

System using automated system processes. These reconciliations shall include:

1227 31.2.9.1 All reconciliations required in the payment processing section1228 31.2.9.2 Separate reconciliations of all types of fees, penalties and

miscellaneous charges1229 31.2.9.3 Reconciliations by payment location, payment method, and fee types1230 31.2.9.4 Identification and resolution of all variances1231 31.2.10 The LPT Processor shall reconcile with banks and processors for cash,

check, electronic funds transfers, ACH, credit/debit cards and any other form of payment regularly accepted using automated system processes. These reconciliations shall include:

1232 31.2.10.1 Separate reconciliations for each bank account and processor 1233 31.2.10.2 Reconciliation to LPT Processor reports 1234 31.2.10.3 Identification and resolution of all variances 1235 32 Auditing 1236 32.1 General Audit Requirements









Requirement



1237 32.1.1 The LPT Processor shall audit internal financial records and operations to ensure that it processes financial transactions accurately and in accordance with approved Policies and Procedures.

1238 32.1.2 The LPT Processor shall hire a major independent certified public accounting firm to perform a Service Organization Control (SOC 1) Type 2 audit annually in accordance with Statement on Standards for Attestation Engagement No.16 (SSAE 16) and provide such report to OTA. This review shall include the effectiveness of operational controls related to software, procedures, data security, processing integrity, confidentiality, and privacy. The costs for such audits shall be borne by the LPT Processor.

1239 32.1.3 The LPT Processor shall facilitate access to any material, system, or personnel that OTA or its authorized representatives require for auditing or examination of the LPT Processor’s activities. Such facilitation shall include LPT Processor staff time and effort working with OTA or its authorized representatives.

1240 32.1.4 The LPT Processor shall develop and submit a remediation plan and remediation schedule to OTA for approval and shall implement all audit recommendations on a timely basis as approved by OTA.

1241 32.2 Internal Controls 1242 32.2.1 The LPT Processor shall establish and follow internal control procedures

to ensure the safeguarding and proper accounting of OTA funds and related records at all times.

1243 32.2.2 Internal controls shall be based on an industry standard such as the 2013 guidance from the Committee of Sponsoring Organizations of the Treadway Commission (COSO), “Internal Control – Integrated Framework”, or other appropriate standard.

1244 32.2.3 The LPT Processor shall ensure that physical access to money, data, other assets, and documents is adequately safeguarded.

1245 32.2.4 The LPT Processor shall detect and prevent revenue loss, errors, omissions, irregularities, and improper actions as well as identify revenue loss, errors, omissions, irregularities, and improper actions after they have occurred. Any occurrence shall be immediately reported to OTA.

1246 32.2.5 The LPT Processors shall ensure that all financial activity is properly processed and accurately recorded.

1247 32.2.6 The LPT Processor shall have controls and procedures in place to ensure that all processing is complete and accurate, including:

1248 32.2.6.1 Sanity checks1249 32.2.6.2 Acknowledgement files









Requirement



1250 32.2.6.3 Prevention of duplicate transactions1251 32.2.6.4 Reconciliations1252 32.2.6.5 Quality Assurance & Quality Control1253 32.2.7 The LPT Processor shall use exception reporting and sanity checks to

detect and list unusual or invalid transactions, adjustments, charges and deviations from proper reconciliation with various components of the financial system.

1254 32.2.8 The LPT Processor shall appropriately segregate duties for various transactions, including handling of cash and checks.

1255 32.2.9 The LPT Processor shall conduct training that details the responsibilities of each employee with regard to internal controls, theft, fraud, embezzlement, fiscal misconduct, and violation of established policies.

1256 32.2.10 The LPT Processor shall use computer system restrictions with varying levels of access control and restrictions on the type of transactions that may be performed by users.

1257 32.2.11 The LPT Processor’s procedures shall require supporting information to verify the propriety and validity of transactions.

1258 32.2.12 The LPT Processor shall ensure that approval authority is commensurate with the nature and significance of the transactions.

1259 32.2.13 The LPT Processor shall remain current with and obey all federal and state applicable laws and regulations and any applicable financial or banking regulations and/or requirements.

1260 33 Reporting 1261 33.1 General Reporting Requirements1262 33.1.1 Through the LPT System, the LPT Processor shall provide all reports

necessary to support the functions outlined in this document.1263 33.1.2 LPT System reports shall contain near real time data except as approved

by OTA during system design. 1264 33.1.3 The LPT System shall allow multiple simultaneous users to generate

reports.1265 33.1.4 The LPT System shall provide all pre-‐defined reports and ad hoc

report/query capabilities without interfering with the normal operations of the LPT System.

1266 33.1.5 The LPT System shall allow users to browse, apply selection criteria, and run reports on demand through a clearly displayed and user-‐friendly graphical user interface (GUI).

1267 33.1.6 All authorized users, including OTA staff and its representatives, shall have direct access and be able to generate system reports without the need for intervention of LPT Processor staff.









Requirement



1268 33.1.7 The LPT System shall offer a robust reporting module that allows users to select date/time ranges, activity type, payment status, and other applicable selection criteria to be determined during the design phase.

1269 33.1.8 The LPT System shall allow users to sort data in reports.1270 33.1.9 LPT System reports shall include sub-‐totals, totals and grand totals as

appropriate.1271 33.1.10 The LPT System shall automatically generate reports at pre-‐determined

configurable intervals or when criteria meet pre-‐determined configurable thresholds.

1272 33.1.11 The LPT System shall allow authorized users to configure reports to be automatically generated on a scheduled basis for a predefined time period.

1273 33.1.12 The LPT System shall support configurable automated distribution of reports via email.

1274 33.1.13 The LPT System shall save all reports generated to a shared archive as configured by report or at the user’s discretion.

1275 33.1.14 The LPT System shall allow authorized users to retrieve archived reports through the reports GUI.

1276 33.1.15 The LPT System shall show reports on screen and allow users to print or to export a report to industry standard formats including Excel, Access, Adobe, PDF, CSV and HTML.

1277 33.1.16 Wherever possible, exported reports shall be formatted to facilitate viewing in the destination format. For example, reports exported to Excel or CSV shall not have header/footer information repeated on multiple pages.

1278 33.1.17 All reports shall contain a standard report header and/or footer that shall include:

1279 33.1.17.1 ID of the user executing the report1280 33.1.17.2 Date/time the report was executed1281 33.1.17.3 Name of the report1282 33.1.17.4 Page number in the format “Page X of Y”1283 33.1.17.5 Selection criteria used to generate the report1284 33.1.17.6 OTA logo or other such identifier (for formats that support this)1285 33.1.18 All reports shall be available to execute for standard user selectable

timeframes including:1286 33.1.18.1 Daily1287 33.1.18.2 Weekly1288 33.1.18.3 Monthly1289 33.1.18.4 Quarterly1290 33.1.18.5 Yearly









Requirement



1291 33.1.19 The LPT System shall allow users to perform business analysis using drill down, graphing, pivoting and cross-‐tabulation.

1292 33.1.20 The LPT System reports database shall contain customer service operations data from the IVR system, website, CSR phone system, Cash Payment Network, and other tools used to provide customer service.

1293 33.1.21 The detailed contents and layout of all system and manual reports and report selection screens shall be developed by LPT Processor and approved by OTA during the design phase.

1294 33.2 Ad Hoc Reports1295 33.2.1 The LPT Processor shall allow for the generation of ad hoc reports

through a user-‐friendly graphical interface.1296 33.2.2 The LPT System shall allow users to run ad hoc queries and generate

reports.1297 33.2.3 The LPT System shall allow users to store ad hoc reports in a common

directory for future access.1298 33.2.4 The LPT System shall allow authorized users to retrieve archived reports

through the reports GUI.1299 33.2.5 The LPT System shall have run-‐time control limits to manage large

queries, print jobs and downloads to prevent interference with normal operations.

1300 33.2.6 The LPT System shall provide pop-‐up warnings to users when requested queries may be large and/or require time to compile.

1301 33.2.7 The LPT System shall allow users to preview ad hoc query results and reports before downloading or printing.

1302 33.3 Research Screens1303 33.3.1 The LPT System shall provide screens that facilitate searching, filtering,

and viewing data available in the LPT System reports database. 1304 33.3.2 The LPT System may limit the number of results returned where not

doing so may impact CSC operations; however, there shall be a notification to the user whenever the data returned has been limited.

1305 33.3.3 The LPT System shall provide the ability to do research in areas including:

1306 33.3.3.1 Transactions1307 33.3.3.2 Payments1308 33.3.3.3 Exceptions1309 33.3.3.4 Accounts1310 33.3.3.5 System alerts and system events1311 33.3.3.6 Data transfer logs1312 33.3.3.7 User tracking logs 1313 33.3.3.8 Image Review









Requirement



1314 33.3.3.9 IVR and Call Center activity1315 33.3.3.10 Cash Payment Network activity1316 33.3.4 LPT System research screens shall allow authorized users to query the

database using single or multiple parameters on any relevant field. For example, for a query of transactions, available fields might include transaction date/time, OCR confidence value, posting date, invoice date, due date, Host transaction number, license plate number, license plate jurisdiction, and transaction status.

1317 33.3.5 The LPT System shall display a list of query results that includes high-‐level information relevant to that query, such as time, transaction number, and type. Details about this summary information shall be determined during the design phase.

1318 33.3.6 The LPT System shall allow the user to select any result from the query results list and view more detailed information and/or link to another relevant screen, such as the related account screen.

1319 33.4 Specific Report Requirements1320 33.4.1 At a minimum, the LPT System shall provide the reports included in this

section; however, this is not all-‐inclusive and shall not relieve the LPT Processor from meeting reporting requirements specifically mentioned or implied in other parts of this Scope of Services.

1321 33.4.2 The LPT Processor shall work with OTA to finalize reports during the design phase.

1322 33.4.3 The LPT System shall provide performance monitoring reports as required to monitor and audit compliance with the Performance Standards detailed in Appendix F.

1323 33.4.4 The LPT System performance monitoring reports shall cover all required Performance Standards, comparing actual performance for each standard with the standard itself.

1324 33.4.5 The LPT System shall provide reports on customer service operations that cover all aspects of customer service on a daily basis and over selected date ranges, at both a summary and detail level.

1325 33.4.6 At a minimum, the LPT System shall provide customer service reports on the following:

1326 33.4.6.1 Customer contacts by contact method, by time period, by type of correspondence, and by topic (e.g., payment, dispute, PIKEPASS conversion)

1327 33.4.6.2 Incoming mail volumes by time period and by type









Requirement



1328 33.4.7 The LPT System shall provide reports on all aspects of the IVR and call center activity to allow users to determine the effectiveness and efficiency of the IVR system and customer service representatives over the phone.

1329 33.4.8 The LPT System shall provide IVR and call center activity reports, at both a detail and a summary level, for various periods including hourly, daily, weekly, monthly and annual.

1330 33.4.9 The LPT System shall provide IVR and call center activity reports that allow users to analyze and compare call center data for similar periods (e.g., the most recent Monday compared to prior Monday and average Monday over the past quarter, year, etc.).

1331 33.4.10 LPT System call center reports shall provide call center data including:1332 33.4.10.1 Call Origin1333 33.4.10.2 Call Volumes1334 33.4.10.3 Call Reason Codes (reason for call)1335 33.4.10.4 Call Wait Times 1336 33.4.10.5 Average Talk Time1337 33.4.10.6 Average Wrap Time1338 33.4.10.7 Total Average Talk and Wrap Time1339 33.4.10.8 Abandoned Calls1340 33.4.10.9 Abandoned Call Rate1341 33.4.10.10 Use of the IVR Menus1342 33.4.10.11 Transfers1343 33.4.11 The LPT System shall provide website reports on all aspects of website to

allow users to determine the effectiveness and usability of the website.

1344 33.4.12 The LPT System shall provide website reports, at both a detail and a summary level, on a daily basis, monthly basis, and over a user-‐selected date range.

1345 33.4.13 LPT System website reports shall provide data including:1346 33.4.13.1 Number of website page hits1347 33.4.13.2 Use of the website page links1348 33.4.13.3 Activity conducted on the web1349 33.4.13.4 Length of time spent on the website1350 33.4.13.5 Payments1351 33.4.13.6 Use of links to OTA website1352 33.4.13.7 Use of links to CPN locator 1353 33.4.14 The LPT System shall provide image review reports that give detail and

summary information for daily, monthly, and user-‐specified date ranges.1354 33.4.15 The LPT System image review reports shall provide data including:









Requirement



1355 33.4.15.1 Number of images received from OTA for review1356 33.4.15.2 Disposition of all images received1357 33.4.15.3 Number of images reviewed1358 33.4.15.4 Number of readable images1359 33.4.15.5 Number of unreadable images by reject code1360 33.4.15.6 Number of images re-‐reviewed1361 33.4.15.7 Number of images reviewed from Watch List1362 33.4.16 The LPT System shall provide reports on LPT accounts with detail and

summary information as follows:1363 33.4.16.1 Account status, including past due statuses1364 33.4.16.2 Newly established accounts1365 33.4.16.3 Accounts with frequent toll activity1366 33.4.16.4 Payment method1367 33.4.16.5 Payments made1368 33.4.16.6 Invoice delivery method1369 33.4.16.7 Account balance1370 33.4.16.8 Invoice Escalation status including invoice aging, violations, collections

and Stop Flag status (all by date)1371 33.4.16.9 Flag for accounts with past CPN activity1372 33.4.17 The LPT System shall provide reports of invoices issued by specific

variables including date, amount due, violation status, payment type, zip code, and mail suppression status.

1373 33.4.18 The LPT System shall provide reports on violations that show, at a detail and a summary level, the current status of all violations.

1374 33.4.19 The LPT System shall provide reports on its interfaces with other systems such as the Host, banks, payment processors, CPN, DMVs and the collection agency.

1375 33.4.20 LPT System interface reports shall provide detail and summary information by date and by interface to:

1376 33.4.20.1 Verify the timely, complete, and accurate transmission of information1377 33.4.20.2 Allow reconciliation between reports on counts and amounts from the

other entity on data sent versus data received1378 33.4.20.3 Identify any corrupt or missing information1379 33.4.20.4 Allow for research of variances identified1380 33.4.21 The LPT System shall provide reports on LPT transaction processing and

disposition that show the current status of all transactions at both a detail and a summary level, by any of the following criteria:

1381 33.4.21.1 Transaction date1382 33.4.21.2 Transmission date1383 33.4.21.3 OCR confidence value









Requirement



1384 33.4.21.4 Posting date 1385 33.4.21.5 Invoice date1386 33.4.21.6 Past due status1387 33.4.21.7 Violation status1388 33.4.22 The LPT System transaction reports shall allow examination by:1389 33.4.22.1 Interim statuses such as image review, ROV look up, queued for

invoicing1390 33.4.22.2 Most recent reconciliation code returned to the Host1391 33.4.22.3 Stage in the invoicing process1392 33.4.22.4 Violation status, including registration stop flag status1393 33.4.22.5 Final statuses such as posted, rejected, paid, turned to collection or

dismissed1394 33.4.23 The LPT System shall provide reports tracking all invoices, escalations and

violation notices sent to customers. 1395 33.4.24 LPT System escalation reports shall allow users to track the current status

of all invoices and violation notices by transaction date (range) and date of invoice/notice issuance. At a minimum, these reports shall allow examination of:

1396 33.4.24.1 Payment details1397 33.4.24.2 Adjustments 1398 33.4.24.3 Write offs1399 33.4.24.4 Tolls 1400 33.4.24.5 Fees1401 33.4.24.6 Vehicle registration stop flags or other escalated collection efforts1402 33.4.24.7 Average payment amounts and length of time until payment1403 33.4.24.8 Aging reports1404 33.4.25 The LPT System shall provide an invoice summary report showing a

current snapshot of all transactions that have been invoiced for a selectable period. This report shall be broken down by invoice escalation status at the time the report is run. The report shall include:

1405 33.4.25.1 The number of transactions invoiced for the period1406 33.4.25.2 The number of transactions by escalation status1407 33.4.25.3 The toll and fee amounts charged by escalation status1408 33.4.25.4 The toll and fee amounts paid by escalation status 1409 33.4.25.5 The toll and fee amounts dismissed/written off, by reason1410 33.4.25.6 The toll and fee amounts due by escalation status1411 33.4.26 The LPT System shall provide reports on all rejected transactions. At a

minimum, these reports shall show at a detail and a summary level the reasons for rejected transactions by transaction date. The reports shall allow analysis of:









Requirement



1412 33.4.26.1 Rejects by reason1413 33.4.26.2 Drill downs into reject reasons 1414 33.4.26.3 DMV lookup failures 1415 33.4.26.4 Trends and variances1416 33.4.26.5 Rejects by jurisdiction1417 33.4.26.6 Repeated attempts at a process such as DMV lookup1418 33.4.26.7 Rejects by stage of transaction processing 1419 33.4.27 The LPT System shall provide all the reports required to audit, reconcile,

monitor and record the financial activity of the LPT operation. 1420 33.4.28 The LPT System shall provide reports on all payments received. 1421 33.4.29 At a minimum, the LPT System payment reports shall provide detail and

summary information by payment date for all payments. 1422 33.4.30 The LPT System payment reports shall allow users to examine payments

by:1423 33.4.30.1 Payment methods1424 33.4.30.2 Payment processor or bank1425 33.4.30.3 Payment location 1426 33.4.30.4 CSR clerk1427 33.4.30.5 Successful versus failed payment attempts1428 33.4.30.6 Reasons for payment failures1429 33.4.30.7 Chargebacks1430 33.4.30.8 Variances between expected totals and actuals 1431 33.4.31 The LPT System shall provide reports on transaction counts and revenue.

At a minimum, these reports shall provide detail and summary information by date and by location.

1432 33.4.32 The LPT System transaction count and revenue reports shall have month and year end roll ups. These revenue reports shall allow users to examine revenue by:

1433 33.4.32.1 Vehicle class1434 33.4.32.2 Collected revenue versus accounts receivable1435 33.4.32.3 Adjustments1436 33.4.32.4 Trend and variance analysis including same month-‐prior year

comparison1437 33.4.32.5 PIKEPASS V-‐Tolls1438 33.4.33 The LPT System shall provide reports on refunds that provide detail and

summary information on refunds. 1439 33.4.34 The LPT System refund reports shall allow users to examine refunds by:1440 33.4.34.1 Request date1441 33.4.34.2 Refund status1442 33.4.34.3 Amount









Requirement



1443 33.4.34.4 Refund reason1444 33.4.34.5 Refunds issued1445 33.4.34.6 Refunds sent to OTA for approval1446 33.4.35 The LPT System shall provide reports necessary for system administration

that give detail and summary information on user activity, system configurations and system issues.

1447 33.4.36 The LPT System admin reports shall allow users to examine:1448 33.4.36.1 User lists1449 33.4.36.2 User permissions1450 33.4.36.3 User activity logs (identifies user, screens viewed, printouts, reports

created, and date and time of use) 1451 33.4.36.4 Automated reports, schedule, and distribution1452 33.4.36.5 System configuration history1453 33.4.36.6 Alerts or alarms1454 33.4.36.7 Maintenance history1455 33.4.37 The LPT Processor shall provide OTA with Monthly Status Reports that

include the following: 1456 33.4.37.1 Number of invoices issued by delivery method1457 33.4.37.2 Number of images reviewed1458 33.4.37.3 Number and percent of rejected images by reason1459 33.4.37.4 Number and percentages of invoices escalated by past due status /

escalation level, including violation (1st notice and 2nd notice), registration stop flag and collections

1460 33.4.37.5 Payments by type; Visa, MasterCard, AMEX, Discover, ACH, cash/check

1461 33.4.37.6 Payments by source; mail, web, LPT CSR call, OTA CSR call, IVR, OTA walk-‐in centers, collection agency, DMV, CPN

1462 33.4.37.7 Total number of customer calls, number of calls entered into a CSR queue, number of calls answered, and number of calls abandoned

1463 33.4.37.8 Number of calls resolved via the IVR by reason1464 33.4.37.9 Average call wait time, average call talk time, average wrap time,

average call handle time (talk and wrap time)1465 33.4.37.10 Average number of daily and monthly calls, average daily calls

answered, average daily calls abandoned (provided in total and by day of the week)

1466 33.4.37.11 Average web access by hour and by day of the week1467 33.4.37.12 Diputes by source1468 33.4.37.13 Refunds by source1469 33.4.37.14 Payments by source1470 33.4.37.15 Progress for the prior month for all outstanding action items









Requirement



1471 33.4.37.16 All potential delays and problems in addressing outstanding issues or software updates

1472 33.4.37.17 New action items and issues1473 33.4.37.18 Progress on activities requiring coordination with OTA or other

external parties1474 33.4.37.19 Deliverables scheduled for submittal in the next reporting period1475 33.4.37.20 Monthly Performance Reports, including comparison to the

Performance Standards1476 33.4.37.21 30-‐day look-‐ahead on activities to clear action items1477 33.4.37.22 Other items as deemed noteworthy by OTA or the LPT Processor1478 34 Performance Standards1479 34.1 General Performance Standard Requirements1480 34.1.1 The LPT Processor shall fully meet or exceed all of the requirements

detailed in this document and the Performance Standards. 1481 34.1.2 In accordance with the requirements of this section, the LPT Processor

shall establish and implement an ongoing process to monitor, measure, calculate, and report compliance with the Performance Standards.

1482 34.1.3 The LPT Processor shall submit the format, content and methodology of all performance reporting to OTA for review and approval during the design phase, in accordance with the approved Project Schedule.

1483 34.1.4 For each of the Performance Standards, the LPT Processor shall measure actual performance for each standard based on the required frequency.

1484 34.1.5 The LPT Processor shall report compliance with each Performance Standard on a monthly basis in conjunction with submitting the invoice payment request to OTA.

1485 34.1.6 If the LPT Processor fails to meet any of the Performance Standards, the LPT Processor shall report the deficiencies, calculate the adjustments, and reduce the LPT Processor’s related pricing categories on the following month’s invoice payment request to OTA.

1486 34.1.7 Non-‐compliance with a Performance Standard and/or the assessment of related invoice adjustments shall not release the LPT Processor from its obligation to complete all required work.

1487 34.1.8 The LPT Processor shall make available to OTA all performance related documentation and reporting, and this will be subject to audit at the discretion of OTA. Actual performance results calculated by the LPT Processor that differ from audited results may be subject to further retroactive adjustment of amounts paid or payable by OTA.

1488 34.1.9 The LPT Processor shall perform all calculations for determining compliance or non-‐compliance with a Performance Standard to three decimal places.









Requirement



1489 34.1.10 The following describes the process and methodology that the LPT Processor shall use in determining compliance/non-‐compliance with Performance Standards, related invoice adjustments and reporting.

1490 34.1.10.1 The determination of compliance or non-‐compliance with each Performance Standard and any resulting invoice adjustment shall be made individually and separately for each standard. For example, if one Performance Standard states that “Paper invoices shall be mailed within 3 calendar days of the invoice date” with an Adjustment Threshold of 98% and another Performance Standard states that “Paper invoices shall be mailed within 5 calendar days of the statement date” with an Adjustment Threshold of 100%; the LPT Processor may be non-‐compliant with one, both, or neither of the two standards. Therefore, depending on compliance, the LPT Processor may be assessed an invoice adjusted for one, both or neither standard.

1491 34.1.10.2 The determination of compliance or non-‐compliance shall be based on the items processed during the specified period (calendar month, day, etc.). For example, if during the month of June, 1,000 images are processed by the LPT Processor; compliance shall be determined based on those specific 1,000 images.

1492 34.1.10.3 Appendix F lists an adjustment threshold for each Performance Standard. If the measured performance of each item meets or exceeds the thresholds, then no adjustment to the invoice for that period is made. However, if the actual performance does not at least meet the threshold on any item, an automatic price adjustment will be triggered and OTA will reduce the invoice amount for the related pricing categories accordingly.

1493 34.1.10.4 Appendix F specifies two methods for calculating the price adjustment depending on the specific Performance Standard. Under one method, the LPT Processor shall adjust the invoice by a specific dollar amount for each instance of non-‐compliance with the Performance Standard. The other method, as described below, requires the LPT Processor to adjust the invoice based on a percentage of the defined pricing categories for the month.









Requirement



1494 34.1.10.5 The percentage method employs tiered adjustment percentages. Invoice payment deductions shall escalate as actual performance results fall further below the required standard. The adjustment percentage shall determine the amount of payment reduction and shall depend on how far the actual performance falls below the adjustment threshold. If the actual performance is below the adjustment threshold by 5% (absolute) or less, the first adjustment percentage shall be used. If the actual performance is more than 5% but less than 15% below the threshold, a higher percentage is used. Finally, if the performance falls to more than 15% below the threshold, an even higher adjustment percentage is used.

1495 34.1.10.6 Each Performance Standard is associated with one or more of the Pricing Categories and is subject to adjustment for non-‐compliance with Performance Standards.

1496 34.1.10.7 More than one pricing category may be related to a Performance Standard. If more than one pricing category is listed for a specific Performance Standard, activity for all the categories shall be combined to calculate compliance with the Performance Standard, with any adjustments for non-‐compliance then being applied to each of the specified pricing categories.

1497 34.1.10.8 The calculated invoice reduction amount for standards that are non-‐compliant shall be increased by 50% if the same standard was found to be non-‐compliant in any of the 3 months immediately prior to the month for which the adjustment is being made. The 50% increase in the invoice reduction shall only be applied to the month being invoiced and not to prior months’ invoices.

Appendix B -‐ Pricing Matrix

Appendix B -‐ Page 1 of 3

Proposed PaymentMilestones for Payment

1 Mobilization (30 days after NTP) 10%

2 Approved System Design Document 25%

3 Successful FAT 25%

4 Successful Go-‐Live 25%

5 Successful SOAT 15%

Operations PhasePrice

Category # Yr. 1 Yr. 2 Yr. 31

A 1 Account to Accounts Required

B Accounts to Accounts Optional

C Accounts to Accounts Optional

D Accounts or more Required

2A 1 Invoice to Invoices Required

B Invoices to Invoices Optional

C Invoices to Invoices Optional

D Invoices or more Required

3A 1 Notice to Notices Required

B Notices to Notices Optional

C Notices to Notices Optional

D Notices or more Required

4A 1 Transaction to Transactions Required

B Transactions to Transactions Optional

C Transactions to Transactions Optional

D Transactions or more Required

5

Design & Development Phase

LPT Account Invoices -‐ Mailed (Paper) $ Amount per Invoice mailed

$ per Email Sent

Additional MailingsEnvelopes Mailed $ per Envelope Mailed

Violations -‐ Mailed $ Amount per Violation Notice mailed

Emails Sent

Account Maintenance -‐ LPT Accounts

$ Amount per Active LPT Account

Design & Development

$ Amount for each transaction that results in the correct identification of a license plate (number, jurisdiction and type)

Post Cards Mailed$ per Item StuffedItems Stuffed$ per Post Card Mailed

RFP PRICING MATRIXProposers Price Form PROPOSED PRICES

Vendor Firm Name:

Initial Contract TermOperations

Image Review



6

7 Succession Implementation Proposed Payment

Vendor Firm Name -‐ Enter Vendor Firm Name

A 1 account to 100,000 accountsB N/A accounts to N/A accountsC N/A accounts to N/A accounts

D 100,001 accounts or more

A 1 account to 100,000 accountsB 100,001 accounts to 700,000 accountsC N/A accounts to N/A accounts


A 1 account to 100,000 accountsB 100,001 accounts to 500,000 accountsC 500,001 accounts to 700,000 accounts


NOTES:

The following costs will be paid directly by OTA or be a direct pass-‐through of actual cost to OTA:PostageCredit Card and ACH Processing FeesBanking Service FeesDMV Look-‐up Fees

DESIGN & DEVELOPMENT PHASE: -‐ Design & Development Phase payments shall be invoiced after OTA's approval of completion of each individual milestone event.

CSR -‐ Call Center

INSTRUCTIONS:

Additional Position 2 (enter job title): $ per Hour

$ per HourCSC Image Review Clerk $ per HourAdditional Position 1 (enter job title): $ per Hour

Hourly Extra Work

Supervisor $ per HourCSR -‐ General $ per Hour

Operations Phase -‐ Year 1 commences with Go-‐Live

Software Developer $ per Hour

Costs Paid by OTA

Unit Prices -‐ Proposers shall enter the proposed unit price that will be charged for each pricing category for years 1, 2 and 3 only. Unit prices for any extension years (if applicable) will be based on the change in the specified Consumer Price Index. The unit price values will be adjusted at the start of each extension year, by an amount not to exceed the lesser of 3% or the change in the U.S. Bureau of Labor Statistics Consumer Price Index -‐ CPI -‐U, US City Average, All Items less food and energy for the most recent calendar year. In no event, however, will the adjustment be less than 0%.

Volume Price Ranges -‐ Proposers may include volume range price break points at which different unit prices would apply for Pricing Categories 1 through 6. Every month the unit prices associated with the applicable ranges will be used for billing purposes for that month. Proposers are required to complete Volume Ranges A and D. In addition, Proposers may include Volume Range B or Volume Ranges B and C. Proposers must insure there are no gaps in Volume Ranges.

For Example, If Using Only Price Ranges A & D:

If Using Price Ranges A & B & D:

If Using Price Ranges A & B & C & D:

EXAMPLE OF THE CALCULATION OF UNIT PRICE TO OTA FOR THE MONTH:

ASSUMING 900,000 UNITS AND VOLUME TIERS AND PRICE BREAKS AS FOLLOWS:

Volume Range (monthly) Unit Price A 1 to 100,000 $0.04 B 100,001 to 500,000 $0.03 C 500,001 to 700,000 $0.02 D 700,001 or more $0.01

THE MONTHLY COST TO OTA WOULD BE $22,000:

100,000 UNITS @ $0.04 = $ 4,000 400,000 UNITS @ $0.03 = $12,000 200,000 UNITS @ $0.02 = $ 4,000 200,000 UNITS @ $0.01 = $ 2,000



OPERATIONAL PHASE:Account Maintenance Fee -‐ UPA Accounts

Invoices Mailed

Violation Notices Mailed

Additional Mailings

Hourly Extra Work

Succession

-‐ Additional Mailings do not include any mailings related to on-‐going customer service. Examples of mailings not included in this category are invoices, escalation notices, vehicle registration hold notices, account maintenance correspondence, and dispute related correspondence. -‐ This category includes only mailings that are specially requested by OTA. Examples of OTA-‐requested mailings may include mass mailings to notify customers of a toll increase, major OTA policy changes, or a road closure.-‐ This fee will be applied to each additional Item mailed/stuffed/emailed during the month being invoiced.

-‐ This is the fully loaded hourly rate that will be applied for any extra work not covered in the Scope of Work. The LPT Processor may add up to 2 additional hourly rate position titles.

-‐ Succession is a task that will be performed by the LPT Processor at the option of OTA and only upon written Notification of Succession by OTA. -‐ Upon Notification of Succession, the LPT Processor shall fully implement the approved Succession Plan. -‐ The Succession payment amount will be paid as follows: 20% paid to the LPT Processor 30 days after Notification of Succession; and the remaining 80% will be paid upon successful completion of the approved Succession Plan and all related activities.

Image Review -‐ The fee will be applied to the total number of transactions that result in the correct identification of a license plate (number, jurisdiction and type) during the calendar month being invoiced. -‐ License plates identified as part of the LPT Processor's QA/QC process or any image re-‐review process are not counted towards the number of plates identified for billing purposes.

-‐ The fee will be applied to the total number of "Active" accounts on the last day of each invoice month. -‐ An "Active" account is defined as an account with a least one toll transaction in the past 2 calendar months (inclusive of the month being invoiced).

-‐ This fee will be applied to the number of paper invoices mailed in the calendar month being invoiced.

-‐ This fee will be applied to the number of paper violation notices mailed in the calendar month being invoiced.

-‐ This fee is intended to cover all costs not specifically covered by another Cost Category.

OTA LPT RFP - Appendix C1

DEFECT BOND BOND NO. KNOW ALL MEN BY THESE PRESENTS:

That ______________________________________________________, whose principal or home office address and telephone number are:

Street/P. O. Box _____________________________________________ City, State, Zip Code ________________________________________ Telephone: (______)_________________, as Principal, and ___________, a

corporation organized in the State of ________________________, and authorized to transact a commercial surety business in the State of Oklahoma, whose principal or home office mailing address is:

Street/P. O. Box _____________________________________________ City, State, Zip Code ________________________________________

as Surety, are held and firmly bound unto the Oklahoma Turnpike Authority, in the penal sum of not less than and no/100 dollars ($ ). in lawful money of the United States of America, said sum being equal to the estimated contract price, for the payment of which well and truly to be made, we bind ourselves and each of us, our heirs, executors, administrators, trustees, successors and assigns, jointly and severally by these presents.

DATED this ______ day of ______________________, 20____. THE CONDITION OF THIS OBLIGATION IS SUCH THAT:

WHEREAS, said Principal entered into a written Contract with the Oklahoma Turnpike Authority dated _____________________, 20____, for the construction or performance of: PROJECT NO.: COUNTY: TURNPIKE: LENGTH: NA DESCRIPTION: LOCATION: (hereinafter the “Project”) all in compliance with the Project plans, specifications and related documents, including all amendments or changes thereto, which documents are on file in the principal office of the Oklahoma Turnpike Authority and are incorporated herein by reference.


NOW, THEREFORE, if the Principal shall properly and timely remedy or correct all defective workmanship and materials appearing in the Project within one year from and after its acceptance by the Oklahoma Turnpike Authority, and if the Principal shall pay or cause to be paid all those entities who furnish labor and material to correct or remedy such defects and shall otherwise hold harmless and indemnify the Oklahoma Turnpike Authority for all costs it might incur in remedying said defects, then this obligation shall be null and void, otherwise to remain in full force and effect.

The Surety agrees that no quantity overruns, changes in the work or alterations in the contract work or documents, whether accomplished by change order, addenda or supplemental agreement, and that no deviations in the plan or mode of procedure specified in the Contract shall have the effect of releasing the Surety from all or any part of its obligations hereunder.

IN WITNESS WHEREOF, the Principal has caused this document to be executed in its name by a duly authorized officer, agent or representative, and the Surety has caused this document to be executed in its name by an authorized attorney-in-fact or corporate officer, effective as of the day and year first above written. THE COMMISSION ON THIS BOND IS BEING PAID TO: ____________________ _____________________________. ATTEST: (Corporation) [SEAL] PRINCIPAL ____________________________ Secretary of the Corporation

By: Individual Proprietor/ Partner/Authorized Officer

SURETY

By: Authorized Attorney-in-Fact or an Authorized Officer of Surety

SUBSCRIBED by the Principal’s representative before me, a Notary Public, on this _____ day of _______________________, 20___.

Notary Public in and for the State of ____________________

My Commission Expires: _______________________ [SEAL]


PERFORMANCE BOND BOND NO. KNOW ALL MEN BY THESE PRESENTS:

That ________________________________________________________, whose principal or home office mailing address and telephone number are:

Street/P. O. Box ____________________________________________ City, State, Zip Code ________________________________________ Telephone (____)______________________ as Principal, and

___________________________, a corporation organized in the State of _____________________, and authorized to transact a commercial surety business in the State of Oklahoma, whose principal or home office mailing address is:

Street/P. O. Box ___________________________________________, City, State, Zip Code _______________________________________,

as Surety, are held and firmly bound unto the Oklahoma Turnpike Authority, in the penal sum of not less than and no/100 Dollars ($ ) in lawful money of the United States of America, said sum being equal to the estimated contract price, for the payment of which well and truly to be made, we bind ourselves and each of us, our heirs, executors, administrators, trustees, successors and assigns, jointly and severally by these presents.

DATED this _______ day of _________________________, 20____. THE CONDITION OF THIS OBLIGATION IS SUCH THAT:

WHEREAS, said Principal entered into a written Contract with the Oklahoma Turnpike Authority dated ______________________, 20____, for the construction or performance of:

PROJECT NO.: COUNTY: TURNPIKE: LENGTH: DESCRIPTION: LOCATION:


(hereinafter the “Project”) all in compliance with the Project plans, specifications and related documents, including all amendments or changes thereto, which documents are on file in the Principal office of the Oklahoma Turnpike Authority and are incorporated herein by reference.

NOW, THEREFORE, if the Principal shall properly and promptly complete the construction Project according to all the contract documents, including all subsequent amendments, changes, addenda, time extensions, alterations and supplemental agreements thereto, then this obligation shall become null and void, otherwise to remain in full force and effect. In the event the Principal is declared by the Oklahoma Turnpike Authority to be in default and the Principal’s right to proceed with the Project work is terminated by the Oklahoma Turnpike Authority or by a court of competent jurisdiction, the Surety shall have the duty to assume and complete all the Contract work and material requirements, including all the amendments, changes, addenda, time extensions, alterations and supplemental agreements thereto. In the event the Surety fully performs its obligations hereunder the Oklahoma Turnpike Authority acknowledges that by law the Surety is subrogated to all the Principal’s rights arising out of the Contract, including all deferred payments, retained percentage and credits due and owing to the Principal at the time of default and termination or to thereafter become due and owing under the contract documents. The Oklahoma Turnpike Authority may at its option offset against the contract earnings any indebtedness or liability which the Principal might have to the Oklahoma Turnpike Authority arising out of the bonded Project including but not limited to liquidated damages, site rental, progressive estimate overpayments and the like. After the Surety has been made whole, the Oklahoma Turnpike Authority may offset against any remaining contract earnings any indebtedness or liability of the Principal arising out of other contracts and dealings.

No quantity overruns, changes in the work, or alterations in or amendments to the contract work or documents, whether accomplished by change order, addenda or supplemental agreement, and no deviations in the plan or mode or procedure specified in the Contract shall have the effect of releasing the Surety from all or any part of its obligations hereunder.

IN WITNESS WHEREOF, the Principal has caused this document to be executed in its name by a duly authorized officer, agent or representative, and the Surety has caused this document to be executed in its name by an authorized attorney-in-fact or corporate officer, effective as of the day and year first above written. THE COMMISSION ON THIS BOND IS BEING PAID TO: _____________________ ______________________________.


ATTEST: (Corporation) [SEAL] PRINCIPAL ____________________________ Secretary of the Corporation

By: Individual Proprietor/ Partner/Authorized Officer

SURETY


SUBSCRIBED by the Principal’s representative before me, a Notary Public, on this _____ day of _______________________, 20___.

Notary Public in and for the State of ___________________



STATUTORY PAYMENT BOND BOND NO. KNOW ALL MEN BY THESE PRESENTS:

That ________________________________________________________, whose principal or home office mailing address and telephone number are:

Street/P. O. Box City, State, Zip Code Telephone (_____) _____________________, as Principal, and

_________________________, a corporation organized in the State of _____________________, and authorized to transact a commercial surety business in the State of Oklahoma, whose principal or home office mailing address is:

Street/P. O. Box City, State, Zip Code

as Surety, are held and firmly bound unto the State of Oklahoma and the Oklahoma Turnpike Authority, in the penal sum of not less than no/100 Dollars ($ ) in lawful money of the United States of America, said sum being equal to the estimated contract price, for the payment of which well and truly to be made, we bind ourselves and each of us, our heirs, executors, administrators, trustees, successors and assigns, jointly and severally by these presents.

DATED this _______ day of _________________________, 20____. THE CONDITION OF THIS OBLIGATION IS SUCH THAT:

WHEREAS, said Principal entered into a written Contract with the Oklahoma Turnpike Authority dated ______________________, 20____, for the construction or performance of:

PROJECT NO.: COUNTY: TURNPIKE: LENGTH: DESCRIPTION: LOCATION:


(hereinafter the “Project”) all in compliance with the Project plans, specifications and related contract documents, including all amendments or changes thereto, which documents are on file in the Principal office of the Oklahoma Turnpike Authority and are incorporated herein by reference.

NOW, THEREFORE, if the Principal shall (1) pay all Project indebtednesses incurred by

said Principal and his/her/its subcontractors and materialmen for all labor, material, rental of machinery or equipment and repair of and parts for equipment as are used and consumed in the performance of the contract; and (2) pay all (a) state and local taxes accruing as a result of the contract, (b) liquidated damages and site rental as may be provided for in the contract documents, and (c) any indebtedness of the Principal to the Oklahoma Turnpike Authority arising out of overpayments of progressive estimates, then this obligation shall be null and void, otherwise to remain in full force and effect.

The intent of the Principal and Surety is that this Statutory Payment Bond, including the benefits or coverages provided herein, all notice requirements and all suit limitations, shall be construed, governed and controlled by Title 61, Oklahoma Statutes, Sections 1 and 2, as those statutes exist on the effective date of the Contract, even though the language of this bond may be more or less restrictive than required by statute.

For value received the Surety agrees that no quantity overruns, changes in the work, or alterations in or amendments to the contract work or documents, whether accomplished by change order, addenda or supplemental agreement, and no deviations in the plan or mode or procedure specified in the Contract shall have the effect of releasing the Surety from all or any part of its obligations hereunder.

IN WITNESS WHEREOF, the Principal has caused this document to be executed in its name by a duly authorized officer, agent or representative, and the Surety has caused this document to be executed in its name by an authorized attorney-in-fact or corporate officer, effective as of the day and year first above written. THE COMMISSION ON THIS BOND IS BEING PAID TO: _____________________ ______________________________. ATTEST: (Corporation) [SEAL] PRINCIPAL ____________________________ Secretary of the Corporation

By: Individual/Proprietor/ Partner/Authorized Officer


SURETY


SUBSCRIBED before me, a Notary Public, by the Principal’s representative on this _____ day of _______________________, 20___.

Notary Public in and for the State of _______________________


Appendix D -‐ OTA PIKEPASS Volumes

Appendix D -‐ Page 1 of 1

NOTE: Except where indicated numbers shown are for ALL Roadways

Elm/Peoria Creek Turnpike All Roadways Elm/Peoria Creek Turnpike All RoadwaysPIKEPASS 4,164,394 33,361,879 118,049,763 PIKEPASS 2,327,609.00$ 20,947,195.00$ 144,859,000.00$ Cash 609,002 7,279,470 49,146,642 Cash 423,635.00$ 4,750,503.00$ 101,211,000.00$ Violations 85,522 737,255 2,794,062 Violations 47,960.00$ 408,487.00$ 1,531,297.00$ Total 4,858,918 41,378,604 169,990,467 Total 2,799,204.00$ 26,106,185.00$ 247,601,297.00$

Elm/Peoria Creek Turnpike All RoadwaysPIKEPASS 85.7% 80.6% 69.4%Cash 12.5% 17.6% 28.9%Violations 1.8% 1.8% 1.6%Total 100% 100% 100%

Calls Received ACH (min) % of Total Calls by DayCustomer Service 1 326,546 03:54 Monday 23%Payments 161,252 02:57 Tuesday 21%Violations 45,944 03:29 Wednesday 18%PIKEPASS Cust Violations 40,042 04:22 Thursday 18%Collections 23,185 03:45 Friday 20%Customer Service 2 15,280 01:31 Saturday 0%Government / Fleet 9,828 02:17 Sunday 0%Spanish 7,037 03:34 Total 100%Recycle / Replace 3,706 03:41Litter Hotline 689 01:51Customer Service 3 210 05:32Total Calls 633,719 03:03

Correspondence Received USPS Fax Email TotalGeneral 22,100 23,400 13,000 58,500Violations 10,400 13,000 3,900 27,300Total 32,500 36,400 16,900 85,800

PIKEPASS Accounts (June 2015) 611,728

Violation Transactions by State # %Oklahoma 526,443 66.7% Dollars by % $ Amount % Transactions # TransactionsTexas 137,917 17.5% Credit/Debit 58.3% 577,265$ 61% 29,444Missouri 21,357 2.7% Cash/Check 41.7% 412,831$ 39% 18,864Arkansas 15,633 2.0% Total 100% 990,096$ 100.0% 48,308Kansas 15,590 2.0%Other 72,506 9.2%

Total 789,446 100%

19%9%16%Dismissed for duplicate transaction on account

Revenue

OTA 2014 -‐ Volumes

Violation Payments by Method

Post to PIKEPASS Accounts (Prior to issuance)Posted to PIKEPASS Accounts after Issuance

Of 2,794,062 Lane Violation Events:

Note: Currently there is no IVR

Market Share

Lane Transactions

RFP Appendix E -‐ OTA DRAFT HOST to LPT System ICD

1

Oklahoma Turnpike Authority 4401 West Memorial Road, Suite 130 Oklahoma City, OK 73134-‐1798

OTA HOST to LPT System Interface Control Document

Prepared for OTA

Version 1.0

5/19/2015


2


Document History Date Revision Author Summary of Changes


3


Table of Contents Document History ....................................................................................................................................... 2

1 Introduction ............................................................................................................................................. 5

1.1 Overview ............................................................................................................................................ 5

1.2 Definitions .......................................................................................................................................... 5

2 General Information ................................................................................................................................ 6

2.1 Data Exchange Format ....................................................................................................................... 6

2.2 Transfer Protocol ............................................................................................................................... 6

2.3 Data Exchanges .................................................................................................................................. 6

3 XML Formatting ........................................................................................................................................ 7

3.1 Built-‐in Data Types ............................................................................................................................. 7

3.2 Complex Types ................................................................................................................................... 7

4 Web Services ............................................................................................................................................ 8

4.1 Processing Guidelines ........................................................................................................................ 8

4.2 Security .............................................................................................................................................. 9

4.2.1 Authentication ............................................................................................................................ 9

4.3 Toll (LPT) Transaction ......................................................................................................................... 9

4.3.1 Description .................................................................................................................................. 9

4.3.1.1 Image Based Transactions ....................................................................................................... 9

4.3.2 Data Flow .................................................................................................................................... 9

4.3.3 Data Elements ........................................................................................................................... 10

4.4 Transaction Reconciliation ............................................................................................................... 11

4.5 Daily Reconciliation .......................................................................................................................... 11

4.5.1 Description ................................................................................................................................ 11

4.5.2 Data Elements ........................................................................................................................... 11

4.5.3 Request Example ...................................................................................................................... 12

<Insert sample XML code> ................................................................................................................. 13

4.6 Acknowledgement Web Service ...................................................................................................... 13

4.6.1 Acknowledgement Format ....................................................................................................... 13

4.6.2 Acknowledgement Ack Code and Ack Message ....................................................................... 14

4.6.3 Acknowledgement XSD ............................................................................................................. 14

<Insert sample code> ......................................................................................................................... 14


4


5 File Transfers ........................................................................................................................................... 14

5.1 Overview .......................................................................................................................................... 14

5.2 OTA File Server ................................................................................................................................ 14

5.2.1 OTA File Server Security ............................................................................................................ 15

5.3 PIKEPASS Account Match Lookup .................................................................................................... 15

5.3.1 Overview and Database Access Method .................................................................................. 15

5.3.2 Transfer Protocol ...................................................................................................................... 15

5.3.3 File Archival ............................................................................................................................... 15

5.3.4 Acknowledgement .................................................................................................................... 15

5.3.5 Directory Structure ................................................................................................................... 15

5.3.6 Data Elements ........................................................................................................................... 16

5.3.7 File Example .............................................................................................................................. 16

5.4 Oklahoma License Plate Lookups ..................................................................................................... 16

5.4.1 Overview and Database View Access Method .......................................................................... 16

5.4.2 OK License Plate Data Security and Retention .......................................................................... 16

5.5 Texas License Plate Lookups ............................................................................................................ 16

5.5.1 Overview and Database View Access Method .......................................................................... 17

5.5.2 TX License Plate Data Security and Retention .......................................................................... 17

5.6 HOT Lists .......................................................................................................................................... 18

5.7 Images .............................................................................................................................................. 18

5.7.1 Overview ................................................................................................................................... 18

5.7.2 Image Quality and Characteristics ............................................................................................ 18

5.7.3 Transfer Protocol ...................................................................................................................... 18

5.7.4 File Archival ............................................................................................................................... 18

5.7.5 Compression ............................................................................................................................. 18

5.7.6 Naming Convention .................................................................................................................. 18


5


1 Introduction

1.1 Overview This Interface Control Document (ICD) is designed to manage and clarify information required to develop the interfaces between the Oklahoma Turnpike Authority (OTA) Host System managed by OTA and the License Plate Tolling (LPT) System managed by the LPT Processor. It includes technical details and operational information necessary to ensure proper usage and support for service operation. This document is intended to serve as a basis for discussions with the successful Proposer (LPT Processor). The final ICD will be developed from this preliminary draft according to provisions in the OTA RFP. The data exchanges and business rules described herein are subject to change, and this document is intended to be a part of the overall change management process when system changes occur that affect the exchange of data between the two systems.

1.2 Definitions Word/Acronym Definition/Term Host OTA cEnterprise – Back Office Hot List A list of license plates OTA wants to be informed

about if read by the LPT System ICD Interface Control Document LPT License Plate Tolling OTA Oklahoma Turnpike Authority PII Personally Identifiable Information Site to Site VPN A secure communication tunnel between two

public facing networks configured to encrypt traffic.

Web service Software designed to support interoperable system-‐to-‐system interaction over a network

XML Extensible Markup Language


6


2 General Information

2.1 Data Exchange Format All data, with the exception of images, will be specified in XML format as defined in the Second Edition of XML Schema documented at: http://www.w3.org/TR/xmlschema-‐0/. Images will be transmitted in Jpeg format, since it is used exclusively by the tolling industry. The LPT Processor can provide further file format requirements during the design phase.

2.2 Transfer Protocol The preferred message protocol is web services. Bulk data and images will be transmitted using SFTP file transfer.

2.3 Data Exchanges

Data Exchange Format Push/Pull Method/Protocol Frequency Toll Transaction (Tag File)

XML OTA Push to LPT Web Service / HTTPS

Continuously – 24/7

Daily Reconciliation Report

XML LPT Push to OTA Web Service / HTTPS

Once per day

Images JPEG OTA Push to LPT File Transfer / SFTP


Transaction Disposition

XML LPT Push to OTA File Transfer / SFTP

TBD – no less than once per day

PIKEPASS DB Access – Account Match

XML LPT Pull from OTA Web Service / HTTPS


License Plate DB Access OK



License Plate DB Access to TX



License Plate DB Access to CVIEW




7


3 XML Formatting XML documents in this interface follow the XML formatting rules as described in the Second Edition of the XML Schema documented at: http//www.w3.org/TR/xmlschema-‐0

3.1 Built-‐in Data Types XML includes data types called built-‐in data types. The following built-‐in data types are used in this ICD:

• int • long • decimal • boolean • date • time • dateTime

The built-‐in data type for date, dateTime, and time allows time zone to be specified. For this interface all date elements will be specified without timezone and will be in the local timezone for Oklahoma City, Oklahoma. The dateTime built-‐in type is:

• Specific instance of time. ISO 8601 extended format • CCYY-‐MM-‐DDThh:mm:ss

Example, to indicate 3:20 pm on June the 21st, 2001 for Central Standard Time, which is 6 hours behind Coordinated Universal Time (UTC): 2001-‐06-‐21T15:20:00-‐06:00

3.2 Complex Types XML allows the definition of complex data types. A basic complex data type extends a simple type by specifying valid values or ranges. Here is an example of a complex type that limits the values to “4” and “5”. The base type is xsd:string. The values are limited with the enumeration keywords. <xsd:simpleType name=”TransactionTypeType”> <xsd:restriction base=”xsd:string”> <xsd:enumeration value=”4”/> <xsd:enumeration value=”5”/> </xsd:restriction> </xsd:simpleType>


8


Complex types may also be used to specify groups of data elements (traditionally called records). Here is an example of a complex type that defines a record: <xsd:complexType name="USAddress" > <xsd:element name="name" type="xsd:string"/> <xsd:element name="street" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/> <xsd:element name="zip" type="xsd:decimal"/> </xsd:complexType> Complex types are discussed in detail at http://www.w3.org/TR/xmlschema-‐0/.

4 Web Services

4.1 Processing Guidelines Web Services will be provided by the OTA Host. The OTA Host calls the LPT System to push data to the LPT Processor or send an acknowledgement. Web Services are accessed through an HTTPS connection over a Site to Site IPSec VPN tunnel. An IPSec VPN tunnel is used to link two networks over an insecure channel (the Internet). It provides a secure "tunnel" from one network to the other. HTTPS is used to secure communications over any network, whether the network is internal (intranet) or external (Internet). While it is not required (with Category 2 data) to encrypt during transmission, we prefer using HTTPS whenever possible. It is more secure, and it is easier to manage from a security standpoint. Using HTTPS should not introduce additional complexity. It will, however, introduce extra processing. The processing load will be determined during the testing phase, at which point the architecture might be modified to address issues. If testing proves the extra processing is an issue, we will look at alternatives. Each Web Service transaction consists of a request and a reply in a synchronous session. If the request is successful, the reply message will include a status code that denotes success. If the request is not successful, the reply message will include an error message. The data exchange preference is only one transaction is sent per request. There is no batching of requests. For example, if the OTA Host needs to upload 500 transactions, there will be 500 toll transactions for a total of 500 requests and 500 replies. This can be agreed up during the design phase.


9


4.2 Security 4.2.1 Authentication Authentication will be implemented via Digital Certificate. OTA will generate self-‐signed x.509 certificates and will distribute the public key to the LPT Processor.

4.3 Toll (LPT) Transaction 4.3.1 Description The purpose of the Toll Transaction web service is to submit toll transactions (postpaid video) to the LPT Processor for posting. The transaction request will contain all required transaction data occurring at the lane so that the LPT System can create an account or apply the transactions to the appropriate customer account. Toll transactions will be sent from the Elm/Peoria Toll Lanes via the OTA Host that require posting to a customer account and are not PIKEPASS based transactions. 4.3.1.1 Image Based Transactions Image based transactions (postpaid video, non PIKEPASS) will include at up to 12 image(s). The Image(s) should also be included, via SFTP, and corresponding transaction ID built into the image name and sequence numbers. 4.3.2 Data Flow Upon receipt of the Web service transaction, the LPT System will perform the following date validation checks:

• Required data elements have been specified • Data elements are of the proper data type and range as specified in the XSD • TransactionDateTime > current date – 60 days (or another duration as negotiated with the

LPT Processor) • No duplicate transaction. The combination of FacilityCode, PlazaCode, LanNumber,

TransactionDateTime, and SequenceNumber guarantees uniqueness for transactions at the lane.

If the transaction passes data validation checks, it will be accepted, and a success code will be returned. It will be stored in the LPT System database and queued for further processing, for example, ROV lookup, and then later posted to the customer’s account.

If the transaction does not pass data validation checks, it will be rejected, and a response code will be returned. It will be stored in the LPT System database, but it will not be posted to the customer’s account. It will be retained in a failed transactions table for later research and/or reporting.


10


Whether the transaction passes or fails data validation checks, it will be committed to the LPT System database before the web service sends an acknowledgement. The transactions that pass data validation will be posted to the appropriate account. Those that fail will be retained in a “failed transactions” table, but they will not be posted to a customer’s account.

4.3.3 Data Elements Tag Name Required Data Type Notes FacilityCode Required String Identifies the tolling facility.

Domain: Facility codes

PlazaCode Required String Code assigned to the plaza or tolling zone. Domain: Plaza codes

LaneNumber Required int Identifies the lane within the plaza or tolling zone. Range: 1 to 99

TransactionDateTime Required dateTime Toll Transaction dateTime in the local time zone. Fractions of seconds are required. Cannot be in the future or more than 60 days in the past.

SequenceNumber Required Long This number along with the PlazaCode, Facility Code, LaneNumber, and TransactionDateTime guarantees uniqueness for transactions at the lane.

TransactionType Optional String Identifies the transaction type photo-‐enforced post paid. Domain: TransactionTypes

AVCClassification Required String Vehicle classification as indentified by Automatic Vehicle Classification system in the lane. Domain: VehicleClassTypes

ImageList Required ImageListType The facility is required to provide images for all transactions

AxleCount Optional int Range: 0 to 15


11


4.4 Transaction Reconciliation A methodology will be developed such that the OTA Host receives an indication, at the transaction level, as to the disposition of the transaction. Disposition status will include, but not be limited to, paid and rejected. In the event that a transaction is rejected a reason code will be provided indicating the reason for the rejection.

4.5 Daily Reconciliation 4.5.1 Description The Daily Reconciliation web service will be executed by the OTA Host once a day to provide reconciliation information to the LPT System. The summary level information will be compared to the data received by the LPT Processor in a LPT System Report. The discrepancies will be highlighted to help identify missing data. For example, if the daily reconciliation web service states that the OTA Host transmitted 1,000 transactions, but the LPT System can only find 500 transactions, there are apparently 500 transactions missing. In this case, the LPT Processor will work with OTA to not only find the missing transactions, but also find the cause for the exclusion. The Daily Reconciliation web service includes the From and To Date/Time range to clearly identify the reporting period of the data included in the summary data. The OTA Host should send summary information for the LPT facilities, plazas, lanes, transaction types, and AVC classifications, even if the transaction counts are zero. This is needed to ensure that all data has been reported.

4.5.2 Data Elements TagName Required? Data Type Notes FromDateTime Requried dateTime Starting date/time of the reporting period ToDateTime Required dateTime Ending date/time of the reporting period ArrayList Required ComplexType ArrayElement minOccurs=”1”

maxOccurs=”unbounded” FacilityCode Required String Identifies the tolling facility.

Domain: FacilityCodes PlazaCode Required String Code assigned to the plaza or tolling region.

Domain: PlazaCodes LaneNumber Required int Identifies the lane within the plaza or tolling

zone. Range: 1 to 99


12


TransactionType Optional String Domain: Transaction Types AVCClassification Required String Vehicle classification as indentified by

Automatic Vehicle Classification system in the lane. Domain: VehicleClassTypes

TransactionCount Required Long Count of transactions

The following are other reconciliation codes that will need to be developed during the design phase.

• Interim – Transaction received by the License Plate Tolling Processor • Rejected – Duplicate transaction • Rejected – Unable to send to DMV/ROV source for lookup • Rejected – Rejected by DMV/ROV source • Rejected – Addressee unknown • Rejected – No DMV reciprocity • Dismissed – OTA request • Dismissed – No longer own vehicle • Interim – In image review • Interim – In DMV look up • Interim – 2nd time through DMV lookup • Interim – Image re-‐review required • Interim – Transaction pre-‐invoiced; awaiting invoice cycle • Interim – Invoiced • Interim – Past due invoice • Interim – Past due 30 days • Interim – Past due 60 days • Interim – Violation • Interim – Partial Paid • Interim – Administrative review • Interim – CC chargeback • Interim – NSF check • Interim – In skip tracing • Interim – TOR • Final – Dismissed for PIKEPASS conversion • Final – Paid Invoice • Final – Paid Past Due • Final – Paid Violation

4.5.3 Request Example


13


<Insert sample XML code>

4.6 Acknowledgement Web Service The LPT System will provide a web service to accept acknowledgement from the OTA Host. The intent of this web service is to provide a generic Ack/Nak service for all OTA to LPT interfaces, including PIKEPASS VTol, OK and TX License Plate lookups. 4.6.1 Acknowledgement Format Field/Element Data Type Required Notes AckData/AckCode xs:int Y Code of Ack returned.

Valid Range: 0-‐999 AckMessage xs:string Y The actual Ack message. (example: “File Name is

missing”, “No file is received in the past hour”, etc…) Valid Range: String

FacilityCodes xs:string Y Indicates the OTA facility that sends the request. Valid Range: TBD

FileName xs:string N This is the same file name in the file sent out to OTA. This field is used to match an acknowledgement to the file sent out. Valid Range: -‐PIKEPASS Account Match: YYYYMMDDHHMMSS_Full_PPVT_XML.ZIP -‐For OK License Plate lookup: YYYYMMDDHHMMSS_OKLPU_XML.ZIP -‐For TX License Plate Lookup: YYYYMMDDHHMMSS_TXLPU_XML.ZIP

InterfaceName xs:string Y It indicates which interface, either PIKEPASS Account Match, OK LPU, TX LPU, TTXFER (toll transaction)


14


4.6.2 Acknowledgement Ack Code and Ack Message Ack Code Ack Message 0 File Received Successfully 11 File cannot be unzipped 12 File cannot be processed 13 File format is not correct 101 Record is blank 102 TheTransponderValidationList is missing 103 The FileGenerateTime is missing 104 The TotalRecordCount is missing

0 Success 1-‐100 File transfer error 101-‐200 OK LPLU errors 201-‐300 TX LPLU errors 999 Unknown Error – Contact Maintenance Group 4.6.3 Acknowledgement XSD <Insert sample code>

5 File Transfers

5.1 Overview File transfers are used instead of web services when bulk data or images must be transmitted.

• Bulk data can be transmitted more efficiently with a file drop architecture than with web services. Web services tend to work better when small amounts of data are needed quickly such as when transactions are streamed to the LPT System.

• Images are a special type of bulk data. Jpeg images can be embedded in XML, but the process is difficult and it has a significant amount of risk. Images can be transferred very easily, however, with file drop architecture.

5.2 OTA File Server OTA will be responsible for providing a file server with SFTP access provided to the LPT Processor. The file server will be used for the files being transferred between OTA and the LPT System. OTA will size and secure the server with respect to its traffic volume specifications. Other files such as daily reconciliation files and any transaction disposition files will also be transferred as required.


15


5.2.1 OTA File Server Security Data residing on the OTA File Server is classified as category 2. Category 2 data does not require encryption, but it does require authentication for access. SFTP is not required for this security classification, but for simplicity sake, all file transfers to and from the LPT System is accomplished with SFTP. FTP is not allowed. Authentication and encryption will be accomplished with SSH v2 public key / private key pairs.

5.3 PIKEPASS Account Match Lookup 5.3.1 Overview and Database Access Method OTA maintains the PIKEPASS system via the Host. It contains all active/inactive PIKEPASS customers. OTA will provide the LPT Processor with access to a read-‐only database view, or result set of a stored query of the PIKEPASS data, so that the LPT System can compare the License Plate number and jurisdiction against the PIKEPASS customer database. Any processed license plates found to be PIKEPASS customers will not be processed by the LPT System. The LPT System will send a file with a list of Toll Transaction IDs and Image IDs that were found to be PIKEPASS matches. The security will be determined during the design phase. The Database Access Method will be determined during the design phase examples are ODBC or web services. The PIKEPASS Account Match file will be sent daily from LPT System to the OTA Host. 5.3.2 Transfer Protocol SFTP will be used for all PIKEPASS Account Match file transfers between the LPT System and the OTA Host File Server. 5.3.3 File Archival PIKEPASS Account Match files should be retained on the LPT System for a period of 30 days. The retention period is optional for the OTA Host. It is suggested in order to support data analysis in the event there are issues with the data. The LPT System is responsible or purging PIKEPASS Account Match files older than 30 days.

5.3.4 Acknowledgement After receiving the PIKEPASS Account Match file, OTA will send and Ack/Nak to the LPT System by calling the LPT System’s web service.

5.3.5 Directory Structure


16


The first level of the directory structure will be PIKEPASSAM (AM = Account Match). The second level will be INBOUND and PROCESSED. When Account Match files are processed they will be moved to be processed by OTA. 5.3.6 Data Elements TagName Required? Data Type Notes TransactionID Y ComplexType Exact match of the TransactionID must be used

to ensure OTA can match it with a stored TransactionID from the Sent queue of Transactions sent by the OTA web service.

ImageID Y ComplexType Exact match of the ImageID must be used to ensure OTA can match the ImageID with the TransactionID from the Sent queue of Images sent via SFTP by OTA.

5.3.7 File Example <Insert PIKEPASS Account Match file data>

5.4 Oklahoma License Plate Lookups 5.4.1 Overview and Database View Access Method OTA will be providing the LPT Processor with read-‐only access to the Oklahoma License Plate database that it maintains from the Oklahoma Tax Authority. The LPT System is required to do an ROV lookup for every OK LPT transaction to ensure it has up to date information for LPT billing, so this data shall be available 24/7/365 and will be kept up to date at a set OTA interval. OTA will maintain a read-‐only database view, or result set of a stored query of the Oklahoma license plate data, on an Internet accessible server via secure connection over Site to Site VPN.

5.4.2 OK License Plate Data Security and Retention The LPT Processor shall take every precaution in securing the OK license plate ROV data once the queries to the database view become data in the LPT System. This data shall be treated as Personally Identifiable Information (PII) and shall be protected using ISO 27001 and the OTA Security Policy as guidelines for preventing unauthorized access to this data. OTA will provide the LPT Processor with specific data retention schedules for OK license plate data that is connected with LPT Customers.

5.5 Texas License Plate Lookups


17


5.5.1 Overview and Database View Access Method OTA will be providing the LPT Processor with read-‐only access to the Texas License Plate database that it maintains from the Texas DMV. The LPT System is required to do an ROV lookup for every TX LPT transaction to ensure it has up to date information for LPT billing, so this data shall be available 24/7/365 and will be kept up to date at a set OTA interval. OTA will maintain a read-‐only database view, or result set of a stored query of the Texas license plate data, on an Internet accessible server via secure connection over Site to Site VPN. 5.5.2 TX License Plate Data Security and Retention The LPT Processor shall take every precaution in securing the OK license plate ROV data once the queries to the database view become data in the LPT System. This data shall be treated as Personally Identifiable Information (PII) and shall be protected using ISO 27001 and the OTA Security Policy as guidelines for preventing unauthorized access to this data. OTA will provide the LPT Processor with specific data retention schedules for OK license plate data that is connected with LPT Customers.

5.6 CVIEW Database Access 5.6.1 Overview and CVIEW Access Method OTA will be providing the LPT Processor with read-‐only access to the CVIEW database that it maintains from a commercial vehicle registration vendor. The LPT System is required to do an ROV lookup for every Commercial LPT transaction to ensure it has up to date information for LPT billing, so this data shall be available 24/7/365 and will be kept up to date at a set OTA interval. OTA will maintain a read-‐only database view, or result set of a stored query of the CVIEW license plate data, on an Internet accessible server via secure connection over Site to Site VPN.

5.6.2 CVIEW Data Security and Retention The LPT Processor shall take every precaution in securing the CVIEW license plate ROV data once the queries to the database view become data in the LPT System. This data shall be treated as Personally Identifiable Information (PII) and shall be protected using ISO 27001 and the OTA Security Policy as guidelines for preventing unauthorized access to this data. OTA will provide the LPT Processor with specific data retention schedules for CVIEW license plate data that is connected with LPT Customers.


18


5.7 HOT Lists OTA will use the agreed upon file transfer method to send the LPT Processor Hot List files. The LPT System shall process the Hot List files and compare license plates in the list to processed license plate image results to look for matches. When matches occur, the LPT System shall send a web service call to the OTA Host to transmit the matches. The OTA Host will send an acknowledgement confirming it has received the Hot List matches.

5.8 Images 5.8.1 Overview The OTA lane hardware will collect video images of vehicles on the Oklahoma Turnpike at Elm/Peoria. These images are used for license plate tolls. Detailed information about the images is recorded in the toll transaction data exchange. Images will be pushed to the LPT System from the OTA Host File Server. 5.8.2 Image Quality and Characteristics Images received from the OTA Host will be subject to Optical Character Recognition (OCR) (for quality assurance) and may be used on customer notices. For OCR purposes, the OTA provided image is expected to have a uniform pixel density of not less than 150 dots per inch across the license plate region. The image shall be crisply focused and display sufficient contrast to facilitate OCR.

5.8.3 Transfer Protocol Secure File Transfer Protocol (SFTP) will be used to push images from the OTA Host file server to the LPT System.

5.8.4 File Archival Images must be retained and purged in accordance with the Data Retention requirements in the LPT Scope of Services and Functional Requirements. Images must be retained in the LPT System for at least 3 years. The LPT Processor is responsible for purging images within 3 months after the required retention timeframe is reached.

5.8.5 Compression Images will not be compressed. Jpeg images do not benefit from compression.

5.8.6 Naming Convention


19


Images will be named in a unique manner by the OTA Host. The image names will be specified in the toll transaction. In order to ensure image names are unique, the following data elements will be specified:

Appendix F -‐ OTA LPT Performance Standards

Appendix F -‐ Page 1 of 5

Impacted PriceCategory

Performance Standards(All Standards are Measured on a Monthly Basis Except as Noted)

Adjustment Threshold

0-‐5% below Threshold

Above 5% but less than 15% below Threshold

15% or more below

Threshold

Compliance Measurement(based on LPT Processor reports)

Invoice & Violation Notice Issuance

1aInvoice Mailed

(paper)Paper invoices (sent via 1st Class Mail) shall be mailed within 2 business days of the end of the billing cycle date. 98% 5% 7% 10%

Invoices mailed within standard/ total invoices which reach the billing cycle for the month

1bInvoice Mailed

(paper)Paper invoices (sent via 1st Class Mail) shall be mailed within 4 business days of the end of the billing cycle date. 100% 5% 7% 10%

Invoices mailed within standard/ total invoices which reach the billing cycle for the month

2aViolations

Notices MailedViolation Notices (sent via Certified Mail) shall be mailed within 3 business days of the end of the billing cycle date. 98% 5% 7% 10%

Violation Notices mailed within standard/ total invoices which reach the billing cycle for the month

2bViolations

Notices MailedViolation Notices (sent via Certified Mail) shall be mailed within 5 business days of the end of the billing cycle date. 100% 5% 7% 10%

Violation Notices mailed within standard/ total invoices which reach the billing cycle for the month

3UPA -‐ Account Maintenance

The LPT Processor shall notify OTA of any license plates that match the PIKEPASS license plate database with 12 hours of identification of the license plate number and jurisdiction.

100% 5% 7% 10%Comparison of LPT Processor report of license plates matching or not matching plates on the PIKEPASS database to the report of all readable images.


All transactions received by the LPT Processor shall be queued for invoicing on an LPT account within 12 hours of identification of Name and Address ROV information.

100% 5% 7% 10%Comparison of LPT Processor report detailing transactions received from OTA to receipt of ROV information


The LPT Processor shall transmit to the OTA Host any changes in transaction reconciliation code status within 24 hours of the change. 100% 5% 7% 10%

Comparison of LPT Processor report detailing transaction status changes to the transmission of status code changes to OTA

6aUPA -‐ Account Maintenance

Name and address look-‐ups shall be initiated with the DMV/OTA/3rd party service within 1 business day of the completion of Image Review. 98% 5% 7% 10%

Comparison of the date a license plate is identified (end of the image review process) to the date the ROV look-‐up process is initiated.

6b UPA -‐ Account Maintenance

Name and address look-‐ups shall be initiated with the DMV/OTA/3rd party service within 3 business day of the completion of Image Review.

100% 5% 7% 10%Comparison of the date a license plate is identified (end of the image review process) to the date the ROV look-‐up process is initiated.

Payments Processing

All cash/check payments received shall be deposited into the designated OTA bank account within 3 business days.

Notes:1) Compliance with this standard will be determined on a Daily basis.

2) Compliance related to payments received will be based on the number of payments, not the dollar value of the payments.

Adjustment Percentages(Reduction for Non-‐Compliance)

Comparison of LPT Processor payment report to bank deposits dates

#

N/A 100% $5,000 per deposit for each day the standard is not achieved.

7

OTA LPTPERFORMANCE STANDARD/THRESHOLDS/ADJUSTMENTS

Transaction Processing








15% or more below

Threshold


Call Center


Calls shall be answered by CSRs within 1 minute of the customers' request to speak to a CSR. 80% 5% 7% 10%

Total number of calls answered by a CSR within 1 minute of the customer selecting the IVR options to speak to a CSR / Total number of calls in which a customer selecting the IVR option to speak to a CSR

8b UPA -‐ Account Maintenance

Calls shall be answered by CSRs within 5 minutes of the customers' request to speak to a CSR.

95% 5% 7% 10%

Total number of calls answered by a CSR within 5 minutes of the customer selecting the IVR options to speak to a CSR / Total number of calls in which a customer selecting the IVR option to speak to a CSR


The LPT Processor shall answer all customer calls requesting to speak to a CSR.

Note: Calls which are abandoned within the first 30 seconds are not considered abandoned calls)

96% 5% 7% 10%Total calls answered by a CSR/Total calls requested to be placed in the CSR IVR queue

9bUPA -‐ Account Maintenance

The LPT Processor shall answer all customer calls requesting to speak to a CSR

Note: Calls which are abandoned within the first 30 seconds are not considered abandoned calls)

93% 5% 7% 10%Total calls answered by a CSR/Total calls requested to be placed in the CSR IVR queue

10UPA -‐ Account Maintenance All incoming customer calls shall be placed in the IVR system. 99.5% 5% 7% 10%

Total calls handled by the IVR (system or CSR) / Total incoming customer calls


One percent of the total CSR customer call interactions shall be monitored and evaluated by the LPT Processor supervisors each month, with every CSR having a minimum of 5 customer interactions monitored per month.

100% 5% 7% 10%Total calls monitored/evaluated for each CSR/Total calls answered for each CSR. Verification of a minimum of 5 calls monitored/evaluated for CSR.

Reporting & Research

12 N/A The LPT Processor shall make all scheduled reports available by 8AM on the day scheduled.

100% Comparison of report schedule to actual report availability to users.

13 N/AThe LPT Processor shall submit a remediation plan for OTA's approval for all PCI audit compliance exceptions within 10 business days of receipt of the audit report.

100%Comparison of the date the audit report is issued to the date the remediation plan is provided to OTA for review and approval.

14 N/A The LPT Processor shall resolve all PCI audit compliance exceptions within the timeframe approved by OTA in the remediation plan.

100%Comparison of the date the exception is resolved (subject to OTA verification) to the approved resolution date in the remediation plan.

15 N/AThe LPT Processor shall submit a remediation plan for OTA's approval for all SSAE 16 compliance exceptions within 10 business days of receipt of the audit report.

100%Comparison of the date the audit report is issued to the date the remediation plan is provided to OTA for review and approval.

16 N/AThe LPT Processor shall resolve all SSAE 16 exceptions within the timeframe approved by OTA in the remediation plan. 100%

Comparison of the date the exception is resolved (subject to OTA verification) to the approved resolution date in the remediation plan.

17 N/A Subpoenas & Freedom of Information Act requests shall be completed and provided to OTA within 10 business days of the request from OTA.

100% Comparison of the date the OTA request is made to the date the complete data is provided to OTA.


$1,000 per request for each day the standard is not achieved.

$1,000 for each day the standard is not achieved.



$200 per report for each day the standard is not achieved.

#









15% or more below

Threshold


System Availability & ResponseThe LPT System shall be available to users with full functionality 24 hours a day, 7 days a week. This Performance Standard will be measured on a quarterly basis. Any invoice adjustment shall be applied to the last month of the quarter being measured.

An available LPT System is defined as the overall LPT System, components, andprocesses provided by the LPT Processor including the LPT System hardware, LPTSystem Software and network communications that are properly functioningand available to collect revenue, exchange data with the Host, properly processthe data, reconcile the data, and provide customer service.

The LPT System shall be considered unavailable (LPT System downtime) if theLPT System is severely degraded causing loss of functionality, application errorsfor multiple users, or prevents access to staff and users. A failure of the IVRsystem or web site not related to the LPT System will not be included in the LPTSystem availability calculation.

Scheduled, approved maintenance that does not exceed 3 hours per quarter will not be counted toward downtime.

Availability = 100% -‐ ([Total number of hours of downtime in the calendar quarter/ Total number of hours in the calendar quarter] x 100)The IVR system shall be available to customers with full functionality 24 hours a day, 7 days a week. This Performance Standard will be measured on a quarterly basis. Any invoice adjustment shall be applied to the last month of the quarter being measured.

An available IVR system is defined as an operating integrated phone system that is properly functioning and available for use by customers to properly access and manage accounts, talk to CSRs, receive and respond to telephone calls.

The IVR system shall be considered unavailable (IVR System downtime) if customers are unable to access account information or manage their account via the IVR.

IVR downtime resulting from the unavailability of the LPT System components that support the IVR shall not be included in the IVR downtime.

Scheduled, approved maintenance that does not exceed 3hours per quarter will not be counted toward downtime.

Availability = 100% -‐ ([Total number of hours of downtime in the calendar quarter/ Total number of hours in the calendar quarter] x 100)

#


5%Availability = 100% -‐ ([Total number of hours of

downtime in the calendar quarter/ Total number of hours in the calendar quarter] x 100)

Availability = 100% -‐ ([Total number of hours of downtime in the calendar quarter/ Total number of

hours in the calendar quarter] x 100)

UPA -‐ Account Maintenance

18 99.80%

19 99.80% 7%UPA -‐ Account Maintenance 10%

7% 10%

5%








15% or more below

Threshold


The website shall be available to users with full functionality 24 hours/day, 7 days/week excluding approved, routine, scheduled maintenance. This Performance Standard will be measured on a quarterly basis. Any invoice adjustment shall be applied to the last month of the quarter being measured.

An available website is defined as an operating and properly functioningwebsite that is available for use and access by the public with full functionality.

The website shall be considered unavailable (website downtime) if customersare unable to access account information via the website, perform all accountfunctions correctly or if the public are unable to access information online.

Website downtime resulting from the unavailability of the LPT System components that support the website shall not be included in the website downtime.

Scheduled, approved maintenance that does not exceed 3 hours per quarter willnot be counted toward downtime.

Availability = 100% -‐ ([Total number of hours of downtime in the calendar quarter/ Total number of hours in the calendar quarter] x 100)

21 UPA -‐ Account Maintenance

The IVR System shall respond to interactive customer specific inquiry from the database within 3 seconds of the customer requests for specific information.

98% 5% 7% 10% Compariosn of the response time within 3 seconds to the total number of requested responses


The LPT System shall produce requested information within 3 seconds of user requests. 98% 5% 7% 10%

Compariosn of the response time within 3 seconds to the total number of requested responses

Image Review

23 Image Review

The LPT Processor shall either determine the license plate number, jurisdiction and plate type, or reject as unreadable, all license plate images provided by OTA within 3 business days of the images being available to the LPT Processor for review.

98% 5% 10% 15%

Comparison of the date license plates are identified or rejected as unreadable to the date the license plate images were submitted to the LPT Processor for processing.

24 Image Review

The LPT Processor shall either determine the license plate number, jurisdiction and plate type, or reject as unreadable, all license plate images provided by OTA within 5 business days of the images being available to the LPT Processor for review.

100% 5% 10% 15%

Comparison of the date license plates are identified or rejected as unreadable to the date the license plate images were submitted to the LPT Processor for processing.

25 Image Review

Rejected license plate images shall be categorized to the correct established rejection code.

98% 5% 7% 10% Compliance shall be determined by OTA based on a sample audit.

#


Availability = 100% -‐ ([Total number of hours of downtime in the calendar quarter/ Total number of

hours in the calendar quarter] x 100)20 UPA -‐ Account

Maintenance 99.80% 5% 7% 10%




Performance Standards Adjustment Threshold



4% or more below

Threshold


License Plates, which are provided by OTA, shall be correctly identified as to plate number, jurisdiction and plate type by the LPT Processor or correctly rejected to the appropriate reject code

99.95%

Determination of Compliance:The LPT Processor shall audit a random, representative sample of transactions to determine whether it has met the image review accuracy standard. The representative sample size shall be such that it ensures a confidence level of 99% and a confidence interval (margin of error) of 1%.

Quarterly, OTA may review the LPT Processor's audit by selecting a random sample of the transactions in the LPT Processor's monthly audits for the quarter. OTA will choose a sample size that ensures a confidence level of 99% and a confidence interval (margin of error) of 1%.

In the event that the OTA audit discloses an error rate in the LPT Processor audit of greater than 2%, an invoice reduction of 10 % of the invoiced line item will be made.

Note: An error in the determination of plate numbers/letter, plate type and/or jurisdiction of issuance, and incorrect rejections of images as unreadable shall be considered failures under this standard.

15% 35%25% See -‐ Determination of Compliance in Performance Standard column

NOTE: CHANGE IN ADJUSTMENT PERCENTAGES FOR # 26

(Reduction for Non-‐Compliance)

#

26 Image Review

ENGR. H. B. NO. 1568 Page 1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

ENGROSSED HOUSE BILL NO. 1568 By: Mulready of the House and Newberry of the Senate

An Act relating to motor vehicles; amending 47 O.S. 2011, Section 11-1401.2, as last amended by Section 28, Chapter 15, O.S.L. 2013 (47 O.S. Supp. 2014, Section 11-1401.2), which relates to the Oklahoma Electronic Toll Collection Act; changing certain definitions; defining terms; providing that certain penalty is in addition to toll charges; providing for a video toll collection system; providing certain notice requirements and information; limiting disclosure of certain information; and providing an effective date.

BE IT ENACTED BY THE PEOPLE OF THE STATE OF OKLAHOMA:

SECTION 1. AMENDATORY 47 O.S. 2011, Section 11-1401.2,

as last amended by Section 28, Chapter 15, O.S.L. 2013 (47 O.S.

Supp. 2014, Section 11-1401.2), is amended to read as follows:

Section 11-1401.2 A. For purposes of this section:

1. "Authority" means the Oklahoma Turnpike Authority;

2. "Commission" means the Oklahoma Tax Commission;

3. "Electronic toll collection system" means a system of

collecting tolls or charges which is capable of charging an account

holder the appropriate toll or charge by transmission of information

Appendix G - Oklahoma Legislation_HB1568

jeffreyweiss

Typewritten Text


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

from an electronic device on a motor vehicle to the toll lane, which

information is used to charge the account the appropriate toll or

charge;

4. "Owner" means any person, corporation, partnership, firm,

agency, association, or organization who, at the time of the

violation and with respect to the vehicle identified in the notice

of toll evasion violation:

a. is the beneficial or equitable owner of the vehicle,

b. has title to the vehicle,

c. is the registrant or coregistrant of the vehicle which

is registered with the Oklahoma Tax Commission or

similar registering agency of any other state,

territory, district, province, nation or other

jurisdiction,

d. subject to the liability limitations set forth in

paragraph 12 of subsection B of this section, uses the

vehicle in its vehicle renting and/or leasing

businesses, or

e. is a person entitled to the use and possession of a

vehicle subject to a security interest in another

person;

5. "Photo-monitoring system" means a vehicle sensor installed

to work in conjunction with a toll collection facility which

automatically produces one or more photographs, one or more


jeffreyweiss

Typewritten Text

jeffreyweiss

Typewritten Text

jeffreyweiss

Typewritten Text


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

microphotographs, a videotape or other recorded images of each

vehicle at the time it is used or operated in violation of toll

collection regulations on the turnpikes under the Authority's

jurisdiction;

6. "Toll collection regulations" means those rules and

regulations of the Oklahoma Turnpike Authority or statutes providing

for and requiring the payment of tolls and/or charges prescribed by

the Authority for the use of turnpikes under its jurisdiction or

those rules and regulations of the Authority or statutes making it

unlawful to refuse to pay or to evade or to attempt to evade the

payment of all or part of any toll and/or charge for the use of

turnpikes under the jurisdiction of the Authority; and

7. "Toll evasion violation" means a failure to comply with the

Authority's toll collection regulations, including the failure to

pay an invoice submitted by the Authority via its video toll

collection system;

8. "Vehicle" means every device in, upon or by which a person

or property is or may be transported or drawn upon a highway, except

devices used exclusively upon stationary rails or tracks; and

9. "Video toll collection system" means a photo-monitoring

system used to charge and collect tolls from owners of vehicles

imaged using the turnpike system. The owner of a vehicle imaged by

the photo-monitoring system may or may not be an Authority account

holder.


jeffreyweiss

Typewritten Text

jeffreyweiss

Typewritten Text


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

B. 1. Notwithstanding any other provision of law, there shall

be imposed monetary liability on the owner of a vehicle for failure

of an operator thereof to comply with the toll collection

regulations of the Oklahoma Turnpike Authority in accordance with

the provisions of this section.

2. The owner of a vehicle shall be liable for a civil penalty

imposed pursuant to this section if the vehicle was used or operated

with the permission of the owner, express or implied, in violation

of the toll collection regulations, and such violation is evidence

by information obtained from a photo-monitoring system. However, no

owner of a vehicle shall be liable for a penalty imposed pursuant to

this section where the operator of the vehicle has been convicted of

a violation of toll collection regulations for the same incident.

3. A certificate, sworn to or affirmed by an agent of the

Authority, or facsimile thereof, based upon inspection of

photographs, microphotographs, videotape or other recorded images

produced by a photo-monitoring system shall be prima facie evidence

of the facts contained therein and shall be admissible in any

proceeding charging a violation of toll collection regulations. The


evidencing such a violation shall be available for inspection and

admission into evidence in any proceeding to adjudicate the

liability for the violation. Each photo-monitoring system shall be

checked bi-monthly bimonthly for accuracy, and shall be maintained,



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

adjusted or replaced if necessary to ensure the systems are

operating properly.

4. An owner found liable for a violation of toll collection

regulations pursuant to this section shall be liable for a monetary

penalty of Twenty-five Dollars ($25.00) for each violation.

Liability for this monetary penalty does not abrogate an owner's

obligation to pay toll charges associated with the violation, and

the Authority may pursue collection of such unpaid toll charges

pursuant to this section.

5. An imposition of liability pursuant to this section shall be

based upon a preponderance of evidence as submitted. An imposition

of liability pursuant to this section shall not be deemed a

conviction as an operator and shall not be made part of the motor

vehicle operating record of the person upon whom such liability is

imposed nor shall it be used for insurance purposes in the provision

of motor vehicle insurance coverage.

6. a. A notice of toll evasion violation shall be sent by

regular first-class mail to each person alleged to be

liable as an owner for a violation of toll collection

regulations. The notice shall be mailed no later than

forty-five (45) days after the alleged violation. A

manual or automatic record of mailing prepared in the

ordinary course of business shall be prima facie

evidence of the receipt of the notice.



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

b. A notice of toll evasion violation shall contain the

name and address of the person alleged to be liable as

an owner for a violation of toll collection

regulations pursuant to this section, the registration

or the license tag number of the vehicle involved in

the violation, the location where the violation took

place photo-monitoring system recorded the vehicle's

image, the date and time of the violation and image,

the identification number of the photo-monitoring

system which recorded the violation image or other

document locator number and the nature of the

violation.

c. Notice of toll evasion violation shall be prepared and

mailed by the Authority or its agents and shall

contain information advising the person of the

applicable monetary penalty and method of payment

thereof and the manner and the time in which the

person may contest the liability alleged in the

notice. The notice of toll evasion violation shall

contain, or be accompanied with, an affidavit of

nonliability and information of what constitutes

nonliability, information as to the effect of

executing the affidavit and instructions for returning

the affidavit to the Authority and shall also contain



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

a warning to advise the persons charged that failure

to contest in the manner and time provided shall be

deemed an admission of liability and that the penalty

shall be imposed and may be collected as authorized by

law. In addition to the notice required by

subparagraph a of this paragraph, the Authority may

elect to send a subsequent notice of toll evasion

violation by certified mail. Such notice shall

contain a statement to the registered owner that,

unless the registered owner pays the toll evasion

penalty or contests the notice within twenty-one (21)

days after receipt of the certified mail notice of

toll evasion violation or completes and files the

affidavit of nonliability, the renewal of the vehicle

registration shall be contingent upon compliance with

the notice of toll evasion violation.

d. If the toll evasion penalty is received by the

Authority and there is no contest as to that toll

evasion violation, the proceedings under this section

shall terminate.

e. If the registered owner fails to pay the toll evasion

penalty as required in this section, or fails to

contest the notice of toll evasion violation issued

pursuant to subparagraph c of this paragraph as



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

provided in subparagraph a of paragraph 7 of this

subsection, the registered owner shall be deemed

liable for the violation by operation of law. The

toll evasion penalty and any administrative fees or

charges shall be considered a debt due and owing the

Authority by the registered owner and the Authority

may proceed to collect such penalty, fees or charges

under paragraph 9 of this subsection.

7. a. Within twenty-one (21) days after receipt of a notice

of toll evasion violation a person may contest a

notice of toll evasion violation. In that case, the

Authority shall do the following:

(1) the Authority shall investigate the circumstances

of the notice with respect to the contestant's

written explanation of reasons for contesting the

toll evasion violation. If, based upon the

results of the investigation, the Authority is

satisfied that the violation did not occur or

that the registered owner was not responsible for

the violation, the Authority shall maintain an

adequate record of the findings of the

investigation. Within thirty (30) days of

receipt of a notice of contest the Authority

shall complete such investigation and mail the



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

results of the investigation to the person who

contested the notice of toll evasion violation,

and

(2) if the person contesting a notice of toll evasion

violation is not satisfied with the results of

the investigation provided for in division (1) of

this subparagraph, the person may, within fifteen

(15) days of the mailing of the results of the

investigation, deposit the amount of the toll

evasion penalty and request an administrative

review. An administrative review shall be held

within ninety (90) calendar days following the

receipt of a request for an administrative

review, excluding any continuance time. The

person requesting the review may request and

shall be allowed one continuance, not to exceed

twenty-one (21) calendar days.

b. The administrative review procedure shall consist of

the following:

(1) the person requesting an administrative review

shall indicate to the Authority his or her

election for a review by mail or personal

conference and may provide materials in support



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

of the contest of the results of the

investigation,

(2) upon ten (10) days' written notice mailed to the

contestant, the administrative review shall be

conducted before an examiner designated to

conduct review by the Authority's governing body

or Director of the Oklahoma Turnpike Authority.

In addition to any other requirements of

employment, an examiner shall demonstrate those

qualifications, training, and objectivity

prescribed by the Authority's governing body or

Director as are necessary and which are

consistent with the duties and responsibilities

set forth in this section and Section 11-1401.1

et seq. of this title,

(3) the officer or person authorized to issue a

notice of toll evasion violation shall be

required to participate in an administrative

review. The Authority shall not be required to

produce any evidence other than the notice of

toll evasion violation or copy thereof, a

photograph of the rear of the vehicle,

information received from the Commission

identifying the registered owner of the vehicle,



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

and a notarized statement from the person

reporting the violations. The documentation in

proper form shall be considered prima facie

evidence of the violation, and

(4) the review shall be conducted in accordance with

paragraph 5 of this subsection and in accordance

with the written procedure established by the

Authority which shall ensure fair and impartial

review of contested toll evasion violations. The

examiner's final decision shall be in writing and

shall be delivered personally or by registered

mail to the contestant within ten (10) days of

the review. A manual or automatic record of

mailing prepared in the ordinary course of

business shall be prima facie evidence of the

receipt of such decision.

8. a. Within twenty (20) days after receipt of the final

decision described in division (4) of subparagraph b

of paragraph 7 of this subsection, the contestant may

seek review by filing an appeal to the district court

having jurisdiction in the county in which the

contestant lives, where the same shall be heard on the

record. A copy of the notice of appeal shall be

served in person or by first-class mail upon the



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

Authority by the contestants. For purposes of

computing the twenty-day period, the Code of Civil

Procedure, Section 2006 of Title 12 of the Oklahoma

Statutes, shall be applicable.

b. The conduct of the hearing on appeal under this

section is a subordinate judicial duty which may be

performed by referees, masters or other subordinate

judicial officials at the direction of the district

court.

c. If no notice of appeal of the Authority's decision is

filed within the period set forth in subparagraph a of

this paragraph, the examiner's decision shall be

deemed final.

9. Except as otherwise provided in paragraphs 10 and 11 of this

subsection, the Authority shall proceed under one or more of the

following options to collect an unpaid toll evasion penalty:

a. the Authority may file an itemization of unpaid toll

evasion penalties and administrative and service fees

with the Commission for collection at the time of

registration of the vehicle pursuant to paragraph 17

of this subsection, or

b. the Authority may contract with a collection agency to

collect unpaid toll evasion penalties, fees, and

charges.



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

10. The Authority shall not file a civil judgment with the

district court relating to a toll evasion violation which has been

filed with the Commission unless the Authority has determined that

the registration of the vehicle has not been renewed for sixty (60)

days beyond the renewal date and the notice has not been mailed by

the Commission pursuant to paragraph 17 of this subsection.

11. If an owner receives a notice of toll evasion violation

pursuant to this paragraph for any time period during which the

vehicle was reported to the police department as having been stolen,

it shall be a valid defense to an allegation of liability for a

violation of toll collection regulations that the vehicle had been

reported to the police as stolen prior to the time the violation

occurred and had not been recovered by such time. If an owner

receives a notice of toll evasion violation pursuant to this

paragraph for any time period during which the vehicle was stolen,

but not yet reported to the police as having been stolen, it shall

be a valid defense to an allegation of liability for a violation of

toll collection regulations pursuant to this paragraph that the

vehicle was reported as stolen within two (2) hours after the

discovery of the theft by the owner. For purposes of asserting the

defense provided by this subsection it shall be sufficient that a

certified copy of the police report of the stolen vehicle be sent by

first-class mail to the Authority and the district court having

jurisdiction.



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

12. An owner of a vehicle to which a notice of toll evasion

violation was issued pursuant to paragraph 6 of this subsection

shall not be liable for the violation of the toll collection

regulations provided that the owner sends to the Authority the

affidavit of nonliability described in paragraph 6 of this

subsection, within twenty-one (21) days after receiving the original

notice of toll evasion violation. Failure to send such information

within the time period shall render the owner liable for the penalty

prescribed by this section. If the owner complies with the

provisions of this subsection, the operator of the vehicle on the

date of the violation shall be subject to liability for the

violation of toll collection regulations, provided that the

Authority mails a notice of toll evasion violation to the operator

within ten (10) days after receipt of such information.

13. In connection with the preparation and mailing of a notice

of toll evasion violation, the Authority shall ensure adequate and

timely notice to all video toll collection system and electronic

toll collection system account holders to inform them when their

accounts are delinquent. An owner who is an account holder under

the video toll collection system or electronic toll collection

system shall not be found liable for a violation of this section

unless the Authority has first sent a notice of delinquency to the

account holder and the account holder was in fact delinquent at the

time of the violation.



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

14. Nothing in this section shall be construed to limit the

liability of an operator of a vehicle for any violation of toll

collection laws or regulations.

15. Notwithstanding any other provision of law, all


prepared pursuant to this section shall be for the exclusive use of

the Authority in the discharge of its duties under this section and

shall not be open to the public nor be used in any court in any

action or proceeding pending therein unless the action or proceeding

relates to the imposition of or indemnification for liability

pursuant to this section. The Authority shall not sell, distribute

or make available in any way, the names and addresses of video toll

collection system and electronic toll collection system account

holders or Authority patrons, without the consent of the account

holders or patrons, to any entity that will use the information for

any commercial purpose.

16. a. Except as provided in subparagraph c of this

paragraph, the Commission shall refuse to renew the

registration of any vehicle if the registered owner or

lessee has been mailed by certified mail a notice of

toll evasion violation as provided in subparagraph c

of paragraph 6 of this subsection, the Authority has

transmitted to the Commission an itemization of unpaid

toll evasion penalties, including administrative fees,



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

pursuant to paragraph 9 of this subsection, and the

toll evasion penalty and administrative fee have not

been paid pursuant to paragraph 8 of this subsection,

unless the full amount of all outstanding toll evasion

penalties and administrative fees, as shown by records

of the Commission are paid to the Commission at the

time of application for renewal.

b. The Authority shall issue a notice of disposition of

toll evasion violation to a lessor, if the lessor

provides the Authority with the name, address, and

driver's license number of the lessee at the time of

the occurrence of the toll evasion violation.

c. The Commission shall renew the registration of any

vehicle if the applicant provides the Commission with

the notice of disposition of toll evasion violation

issued pursuant to subparagraph b of this paragraph

for clearing all outstanding toll evasion penalties,

fees and assessments, as shown by the records of the

Commission, and the applicant has met all other

requirements for registration.

17. The Commission shall include on each vehicle registration

renewal notice issued for use at the time of renewal, or on an

accompanying document, an itemization of unpaid toll evasion

penalties, fees and assessments, showing the amount thereof and the



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

date of toll evasion relating thereto, which the registered owner or

lessee is required to pay pursuant to paragraph 16 of this

subsection.

18. a. Except as provided in subparagraph b of this

paragraph, the Commission shall remit all toll evasion

penalties, fees and assessments collected, after

deducting the administrative fee authorized by

paragraph 19 of this subsection, for each notice of

toll evasion violation for which toll evasion

penalties, fees and assessments have been collected

pursuant to paragraph 16 of this subsection, to the

Authority. Within forty-five (45) days from the time

penalties, fees and assessments are paid to the

Commission, the Commission shall inform the Authority

which of its notices of toll evasion violation have

been collected.

b. For each notice of toll evasion violation for which

toll evasion penalties, fees and assessments have been

collected by the Commission pursuant to paragraph 16

of this subsection, the Authority is due an amount

equal to the sum of the unpaid toll, administrative

fees, other costs incurred by the Authority that are

related to toll evasion, process service fees, and

fees and collection costs related to civil debt



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

collection. After deducting the Commission's

administrative fee authorized by paragraph 19 of this

subsection, the Commission shall promptly pay to the

Authority the amounts due the Authority for unpaid

tolls, administrative fees, other costs incurred by

the Authority that are related to toll evasion,

process service fees, and fees and collection costs

related to civil debt collection.

19. The Commission shall assess a fee for the recording of the

notice of toll evasion violation, which is given to the Commission

pursuant to paragraph 9 of this subsection, in an amount, as

determined by the Commission, that is sufficient to provide a total

amount equal to at least its actual costs of administering

paragraphs 16, 17 and 20 of this subsection.

20. Whenever a vehicle is transferred or not renewed for two

(2) renewal periods and the former registered owner or lessee of the

vehicle owes a toll evasion penalty and administrative fees for a

notice of toll evasion violation filed with the Commission pursuant

to paragraph 9 of this subsection, the Commission shall notify the

Authority of that fact and is not required thereafter to attempt

collection of the toll evasion penalty and administrative fees.

This legislation shall not be construed to affect in any way the

power which the Oklahoma Turnpike Authority possesses to establish

tolls and other charges in connection with their turnpike



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

facilities, including the authority to establish a one-way toll

collection system for any of its facilities or a toll discount

structure for certain classes of patrons using any of its

facilities.

SECTION 2. This act shall become effective November 1, 2015.

Passed the House of Representatives the 9th day of March, 2015.

Presiding Officer of the House of Representatives

Passed the Senate the ___ day of __________, 2015.

Presiding Officer of the Senate


Appendix H – OTA Physical Security Policy

PHYSICAL SECURITY Section: Physical Security

Effective Date: 06-01-2011

Policy Number: IS-005

Date Last Approved by ITSC: 5/21/2015

Prior Policy Number: N/A

Department: All Departments

Initial Policy Date: 06-01-2011

Prior Effective Date: FIRST RELEASE

Purpose Securing physical access to sensitive information and systems is the first step in limiting potential compromise of company data. This policy details the standards that must be implemented to prevent unauthorized access, damage and interference to Oklahoma Turnpike Authority facilities and operations to include unauthorized access to sensitive systems.

Policy Statement Physical access to facilities, data centers, systems, networks and data at Oklahoma Turnpike Authority will be limited to those authorized personnel who require access to perform assigned duties. Where systems are deployed in areas where controls may not completely restrict access to only authorized personnel, monitoring controls will be deployed to identify unauthorized access to systems, network, and data. In addition to access controls, physical safeguards will be deployed to protect sensitive systems and data from fire, theft or other hazard.

Applicability The policy applies to all Oklahoma Turnpike Authority employees, contractors, vendors, and any other person using or accessing Oklahoma Turnpike Authority information or information systems. Exceptions to this policy must be documented and approved by the OTA Leadership or designated representatives.

Standards The following standards will be implemented to mitigate risk of unauthorized access to sensitive Oklahoma Turnpike Authority systems and data. Specific guidelines for the physical security of Oklahoma Turnpike Authority are outlined in the IT Facility Security Plan. BUILDING PERIMETER SECURITY

• All external doors except for the front door into the lobby will be locked at all times and require keys to enter.

• All visitors obtaining access to Oklahoma Turnpike Authority facilities must register at the lobby and remain supervised when on the premises. An IT department representative must accompany all visitors, vendors, contractors and staff while accessing the computer room.

• If not escorted, visitors will be assigned a badge that clearly identifies them as a visitor. INTERNAL SECURITY

• Access to all infrastructure computing/networking devices (i.e., routers, hubs, firewalls, servers, network jacks, etc.) must be restricted to only Oklahoma Turnpike Authority employees with a demonstrated need for recurring access. Separate physical control and access verification must be provided for these devices.

• Access to other network infrastructure components, such as network cables, will be controlled by Oklahoma Turnpike Authority to prevent unauthorized intrusion into our network.


• When employment is terminated, all physical access to Oklahoma Turnpike Authority facilities must be revoked immediately and all physical access tokens (i.e., IDs, keys, magnetic stripe cards, etc.) must be recovered.

• Physical access to wireless access points, gateways and handheld devices will be restricted. Access will be granted only to specific IT personnel or as approved by the IT Leadership.

• Network jacks will be enabled only when required by authorized employees • Video cameras will be used to monitor the entry/exit points of the data center and other

sensitive areas where sensitive data is stored or present. Video cameras will be placed inside the data center to inhibit tampering and must directly monitor systems which store aggregated payment card data. This video will be kept for a minimum of 90 days.

WORKSTATION SECURITY

• User workstations must not be left unattended when logged into sensitive systems or data. Automatic log off and password screen savers will be deployed to enforce this requirement.

• All equipment that contains customer information will be secured to deter theft. In the case of mobile computing devices, all sensitive data must be encrypted when removed from organizational premises.

• Workstation monitors and system terminals will be positioned to limit inadvertent viewing by visitors and other unauthorized system users.

DATA CENTER SECURITY

• Oklahoma Turnpike Authority datacenters will be partitioned by full walls to ensure all access can be monitored.

• The door key system must record date, time and user entering the room and must verify that only authorized users gain access to restricted data rooms.

• Data center walls, doors, and windows will be constructed with sufficient strength to deter entry by an intruder.

• Each critical device will be served by dual power sources. In the event one power source fails the second power source will continue operations for at least 15 minutes.

• Before the addition of any new equipment, the IT department must assure that rack capacity, electrical capacity and bandwidth capacity are sufficiently available.

• All flows of air, gas, and water into the computing facility must have shutoff valves and provide positive drains.

• Multiple layers of protection will be instituted to protect access to the Data Center. Access to the Data Center will require an additional keys or tokens approved by the Information Security Officer.

• Emergency lighting will be maintained in both the computer room and other areas of the organization where sensitive information is stored.

VISITORS It is essential that all persons who enter Oklahoma Turnpike Authority facilities are authorized and that an audit trail exists for all non-Oklahoma Turnpike Authority staff entering Oklahoma Turnpike Authority facilities. Generally, this would be the Guest Check-in log at the receptionist, and/or the Visitation log in the Data Center. Visitor logs will be retained for a minimum of three months. The following special requirements apply for visitors:

• Management or designee must authorize any visitors prior to entering areas where cardholder data is processed or maintained within Oklahoma Turnpike Authority facilities.

• Managers responsible for specific internal space with additional controls must approve visitor access to those areas.

• Visitors will be given a physical token (e.g., badge or access device) that expires, and that identifies them as non-employees.

• Visitors will be required to surrender badges before leaving the facility or on the date of expiration.

• Visitors will be required to sign the Visitor’s Log at the receptionist. Visitor logs will be retained for a minimum of three months.


IDENTIFICATION BADGES Everyone is required to visibly display an identification badge while within Oklahoma Turnpike Authority premises. Employees must challenge anyone not displaying a badge. Particular care must be taken to ensure all persons have authorized badges when entering the facility. Persons without proper access authorizations must be escorted or directed to the security group/receptionist at their site. All lost badges must be reported to Facilities Security as soon as they are discovered missing. All employees are expected to use their own identification badge for access into the building as well as any restricted areas.

References 1. ISO 27002 Section 9 Physical and Environmental Security 2. FFIEC IS Handbook Physical Access 3. GLBA Part 208.3 III C 1 b Access Restrictions 4. Payment Card Industry (PCI) Data Security Standard, Requirement 8.1.8: If a session has been idle for more

than 15 minutes, require the user to re-authenticate to re-activate the terminal or session. 5. Payment Card Industry (PCI) Data Security Standard, Requirement 9.1: Use appropriate facility entry controls

to limit and monitor physical access to systems in the cardholder data environment. 6. Payment Card Industry (PCI) Data Security Standard, Requirement 9.2: Develop procedures to easily

distinguish between osite personnel and visitors, to include identifying new onsite personnel or visitors (for example, assigning badges), changes to access requirements, revoking or terminating onsite personnel and expired visitor identification (such as ID badges).

7. Payment Card Industry (PCI) Data Security Standard, Requirement 9.3: Control physical access for onsite personnel to the sensitive areas as follows: access must be authorizied and based on job function, access revoked immediately upon termination and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.

8. Payment Card Industry (PCI) Data Security Standard, Requirement 9.4: Implement procedures to identify and authorize visitors. Visitors are authorized before entering, and escorted at all times within areas where cardholder data is processed or maintained. Visitors are identified and given a badge or other identification that expores and that visibly distinguishes the visitors from onsite personnel. Visitors are asked to surrender gthe badge or identification before leaving the facility or at the date of exporation. Use a visitor log to maintain a physical audit trail of visitor activity. Document the visitor’s name, the firm represented, and the employee authorizing physical access on the log. Retain this log for a minimum of three months, unless otherwise restricted by law

9. Payment Card Industry (PCI) Data Security Standard, Requirement 9.10: Ensure that security policies and operational procedures for restricting physical accesss to cardholder data are documented, in use, and known to all affected parties.


PHYSICAL SECURITY Section: Physical Security

Effective Date: 06-01-2011

Policy Number: IS-005

Date Last Approved by ITSC: 5/21/2015

Prior Policy Number: N/A

Department: All Departments

Initial Policy Date: 06-01-2011

Prior Effective Date: FIRST RELEASE

Purpose Securing physical access to sensitive information and systems is the first step in limiting potential compromise of company data. This policy details the standards that must be implemented to prevent unauthorized access, damage and interference to Oklahoma Turnpike Authority facilities and operations to include unauthorized access to sensitive systems.

Policy Statement Physical access to facilities, data centers, systems, networks and data at Oklahoma Turnpike Authority will be limited to those authorized personnel who require access to perform assigned duties. Where systems are deployed in areas where controls may not completely restrict access to only authorized personnel, monitoring controls will be deployed to identify unauthorized access to systems, network, and data. In addition to access controls, physical safeguards will be deployed to protect sensitive systems and data from fire, theft or other hazard.

Applicability The policy applies to all Oklahoma Turnpike Authority employees, contractors, vendors, and any other person using or accessing Oklahoma Turnpike Authority information or information systems. Exceptions to this policy must be documented and approved by the OTA Leadership or designated representatives.

Standards The following standards will be implemented to mitigate risk of unauthorized access to sensitive Oklahoma Turnpike Authority systems and data. Specific guidelines for the physical security of Oklahoma Turnpike Authority are outlined in the IT Facility Security Plan. BUILDING PERIMETER SECURITY

• All external doors except for the front door into the lobby will be locked at all times and require keys to enter.

• All visitors obtaining access to Oklahoma Turnpike Authority facilities must register at the lobby and remain supervised when on the premises. An IT department representative must accompany all visitors, vendors, contractors and staff while accessing the computer room.

• If not escorted, visitors will be assigned a badge that clearly identifies them as a visitor. INTERNAL SECURITY

• Access to all infrastructure computing/networking devices (i.e., routers, hubs, firewalls, servers, network jacks, etc.) must be restricted to only Oklahoma Turnpike Authority employees with a demonstrated need for recurring access. Separate physical control and access verification must be provided for these devices.

• Access to other network infrastructure components, such as network cables, will be controlled by Oklahoma Turnpike Authority to prevent unauthorized intrusion into our network.


• When employment is terminated, all physical access to Oklahoma Turnpike Authority facilities must be revoked immediately and all physical access tokens (i.e., IDs, keys, magnetic stripe cards, etc.) must be recovered.

• Physical access to wireless access points, gateways and handheld devices will be restricted. Access will be granted only to specific IT personnel or as approved by the IT Leadership.

• Network jacks will be enabled only when required by authorized employees • Video cameras will be used to monitor the entry/exit points of the data center and other

sensitive areas where sensitive data is stored or present. Video cameras will be placed inside the data center to inhibit tampering and must directly monitor systems which store aggregated payment card data. This video will be kept for a minimum of 90 days.

WORKSTATION SECURITY

• User workstations must not be left unattended when logged into sensitive systems or data. Automatic log off and password screen savers will be deployed to enforce this requirement.

• All equipment that contains customer information will be secured to deter theft. In the case of mobile computing devices, all sensitive data must be encrypted when removed from organizational premises.

• Workstation monitors and system terminals will be positioned to limit inadvertent viewing by visitors and other unauthorized system users.

DATA CENTER SECURITY

• Oklahoma Turnpike Authority datacenters will be partitioned by full walls to ensure all access can be monitored.

• The door key system must record date, time and user entering the room and must verify that only authorized users gain access to restricted data rooms.

• Data center walls, doors, and windows will be constructed with sufficient strength to deter entry by an intruder.

• Each critical device will be served by dual power sources. In the event one power source fails the second power source will continue operations for at least 15 minutes.

• Before the addition of any new equipment, the IT department must assure that rack capacity, electrical capacity and bandwidth capacity are sufficiently available.

• All flows of air, gas, and water into the computing facility must have shutoff valves and provide positive drains.

• Multiple layers of protection will be instituted to protect access to the Data Center. Access to the Data Center will require an additional keys or tokens approved by the Information Security Officer.

• Emergency lighting will be maintained in both the computer room and other areas of the organization where sensitive information is stored.

VISITORS It is essential that all persons who enter Oklahoma Turnpike Authority facilities are authorized and that an audit trail exists for all non-Oklahoma Turnpike Authority staff entering Oklahoma Turnpike Authority facilities. Generally, this would be the Guest Check-in log at the receptionist, and/or the Visitation log in the Data Center. Visitor logs will be retained for a minimum of three months. The following special requirements apply for visitors:

• Management or designee must authorize any visitors prior to entering areas where cardholder data is processed or maintained within Oklahoma Turnpike Authority facilities.

• Managers responsible for specific internal space with additional controls must approve visitor access to those areas.

• Visitors will be given a physical token (e.g., badge or access device) that expires, and that identifies them as non-employees.

• Visitors will be required to surrender badges before leaving the facility or on the date of expiration.

• Visitors will be required to sign the Visitor’s Log at the receptionist. Visitor logs will be retained for a minimum of three months.


IDENTIFICATION BADGES Everyone is required to visibly display an identification badge while within Oklahoma Turnpike Authority premises. Employees must challenge anyone not displaying a badge. Particular care must be taken to ensure all persons have authorized badges when entering the facility. Persons without proper access authorizations must be escorted or directed to the security group/receptionist at their site. All lost badges must be reported to Facilities Security as soon as they are discovered missing. All employees are expected to use their own identification badge for access into the building as well as any restricted areas.

References 1. ISO 27002 Section 9 Physical and Environmental Security 2. FFIEC IS Handbook Physical Access 3. GLBA Part 208.3 III C 1 b Access Restrictions 4. Payment Card Industry (PCI) Data Security Standard, Requirement 8.1.8: If a session has been idle for more

than 15 minutes, require the user to re-authenticate to re-activate the terminal or session. 5. Payment Card Industry (PCI) Data Security Standard, Requirement 9.1: Use appropriate facility entry controls

to limit and monitor physical access to systems in the cardholder data environment. 6. Payment Card Industry (PCI) Data Security Standard, Requirement 9.2: Develop procedures to easily

distinguish between osite personnel and visitors, to include identifying new onsite personnel or visitors (for example, assigning badges), changes to access requirements, revoking or terminating onsite personnel and expired visitor identification (such as ID badges).

7. Payment Card Industry (PCI) Data Security Standard, Requirement 9.3: Control physical access for onsite personnel to the sensitive areas as follows: access must be authorizied and based on job function, access revoked immediately upon termination and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.

8. Payment Card Industry (PCI) Data Security Standard, Requirement 9.4: Implement procedures to identify and authorize visitors. Visitors are authorized before entering, and escorted at all times within areas where cardholder data is processed or maintained. Visitors are identified and given a badge or other identification that expores and that visibly distinguishes the visitors from onsite personnel. Visitors are asked to surrender gthe badge or identification before leaving the facility or at the date of exporation. Use a visitor log to maintain a physical audit trail of visitor activity. Document the visitor’s name, the firm represented, and the employee authorizing physical access on the log. Retain this log for a minimum of three months, unless otherwise restricted by law

9. Payment Card Industry (PCI) Data Security Standard, Requirement 9.10: Ensure that security policies and operational procedures for restricting physical accesss to cardholder data are documented, in use, and known to all affected parties.