35077 Attachment F_Verification Cross Reference Index~1.xlsx
XLSX spreadsheet 46 KB Posted
- Attached to
- Road Usage Charge Commercial Account Manager
- Solicitation number
- S-73000-00004198
- Issued by
- Marion County, Oregon
About this file
This document is a Request for Qualifications (RFQ) issued by the Oregon Department of Transportation (ODOT) for a Commercial Account Manager to support ODOT's Road Usage Charge program. The purpose is to establish replacement Price Agreements for one or more Commercial Account Managers to provide travel data collection equipment, related services, account management services, and customer support. The RFQ includes jurisdictions in Marion County and the City of Salem. Responses are due by a specific date, and ODOT will award contracts for a multi-year term with possible renewal options.
The RFQ outlines detailed requirements and specifications for the Commercial Account Manager, including financial stability, accounting practices, data security and protection, personnel vetting, reporting, and other operational capabilities. The Commercial Account Manager will be responsible for enrolling participants, managing accounts, calculating and collecting road usage charges, providing customer support, and reporting data to ODOT. Pricing terms, funding sources, and other commercial considerations are not explicitly stated in the RFQ.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 35077 Attachment L_COBID DBE Goals~1.docx | DOCX document | |
| 35077 Attachment M_Price Proposal~1.xlsx | XLSX spreadsheet | |
| 35077 CAM RFQ~1.docx | DOCX document | |
| 35077 Attachment A_Sample Price Agreement~1.docx | DOCX document | |
| 35077 Attachment B_Program Requirements Document~3.pdf | ||
| 35077 Attachment C_Interface Control Document~1.pdf | ||
| 35077 Attachment I_Proposer Certification Sheet~1.docx | DOCX document | |
| 35077 ITA.docx | DOCX document | |
| RFP 7154-22_Management of OR MEP_NoticeOfIntentToAward_082922~1.pdf | ||
| 35077 Attachment J_Disclosure Exemption~1.docx | DOCX document | |
| 35077 Attachment K_Responsibility Inquiry~1.docx | DOCX document | |
| ITA ClearRoad.pdf | ||
| 35077 Attachment D_Service Level Agreement~1.pdf | ||
| 35077 Attachment E_Pilot Management Expectations~1.docx | DOCX document | |
| 35077 Attachment G_RUC Table~1.xlsx | XLSX spreadsheet | |
| 35077 Attachment H_Sample WOC~1.docx | DOCX document |
Show all 16
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
CAM
| ATTACHMENT F | |||||||
| VERIFICATION CROSS REFERENCE INDEX | |||||||
| BRD Req # | DESCRIPTION | TYPE OF SUBMISSION FOR EACH PHASE OF CERTIFICATION | Vendor Cross Reference | ||||
| (doc name, page/section/test case # if applicable) | COMPLIANCE STATUS (ODOT) | STATUS DATE | |||||
| Self-Certification | Interface Testing | End to End Testing |
| 2.1 - GENERAL BUSINESS REQUIREMENTS (GBR) | |
| GBR.1 | The BP shall be financially stable through the duration of this Price Agreement (PA). The BP shall be able to provide proof of sustainable business for the past three (3) years at the time of PA establishment. If the BP is a joint venture, then each company comprising the joint venture shall provide proof of business for at the past two (2) years at the time of PA establishment and provide a letter of commitment for sustained business for one (1) year. |
BP shall provide proof of financial stability. This proof shall consist of a Dun & Bradstreet Rating (or equivalent) Classification of 1A or higher, and a Composite Credit Rating of “Good (2)” or “High (1)”.
| GBR.2 | The BP shall use generally accepted accounting principles (GAAP). BP accounting systems shall incorporate industry accepted accounting principles, including separation of duties. |
| GBR.3 | The BP’s corporate financial records shall be auditable. |
| GBR.4 | The BP shall have documented in-place processes for Change and Configuration Management that includes a review period for system changes. For system changes that impact the functionality of the system, Administrator approval is needed. |
| GBR.5 | The BP shall have documented in-place processes and systems for disaster recovery and continuity of operations. |
| GBR.6 | The BP shall conduct banking within the United States. The BP shall have a dedicated U.S. based bank account for all financial transactions, which occur under this Price Agreement. The BP shall be able to remit payments by mail and electronic banking. |
| GBR.7 | All BP’s associated with creating, receiving, sending, and storing RUC travel data, PII, and financial transactions must provide the Administrator an SSAE-18 SOC 2 Type 2 (or equivalent) audit performed within the last one year. |
| 2.2 - GENERAL SYSTEM REQUIREMENTS (GSR) | |
| GSR.1 | The system shall be auditable in order to validate data received from the vehicle and processed, delivered, or received by any subsystem. |
| GSR.2 | The system shall collect data to support the calculations for road usage charge. |
| GSR.3 | The system shall provide credits for applicable fuel taxes. |
| GSR.4 | The system shall collect road usage charge only for taxable miles, as defined by the Administrator. |
| GSR.5 | The system shall align with the RUC open architecture. |
| GSR.6 | The BP system shall have a test environment(s) in addition to a production environment(s). The test environment shall allow the creation of test accounts and shall be exclusive of the production environment. The test environment shall exclusively be used for testing new software and all messages defined in the ICD, before release to the production environment. |
| 2.3.1 - DATA PROTECTION (DP) | |
| SS.DP.1 | The BP shall provide a system architecture diagram that illustrates each component with the RUC Program systems and their interactions. |
| SS.DP.2 | The BP shall provide the physical location of the RUC program system servers. |
| SS.DP.3 | The BP shall provide the security measures implemented across the RUC program system. |
| SS.DP.4 | The BP shall document the implemented process for Information Asset Classification in accordance with the Administrator’s Information Asset Handling Requirements that will be provided by the Administrator. |
| SS.DP.5 | The BP shall document the personally-identifiable information (PII) that is stored, and the corresponding system the data is stored in, and the operational controls that maintain the appropriate level of security and access to the PII. |
| SS.DP.6 | The BP shall make the Administrator aware of any system breach or potentially significant informational breach immediately upon discovery. |
| SS.DP.7 | The BP shall provide data masking for all participant financial information from its employees. At a minimum, means of financial information (including but not limited to ACH, credit and debit card data) shall be masked. |
| SS.DP.8 | The BP shall provide a data modification notification to the participant, through the account contact method provided, as soon as changes are saved in the account information. |
| SS.DP.9 | The BP shall refer to the Oregon state data retention statutes for clarification: http://arcweb.sos.state.or.us/pages/rules/oars_100/oar_166/166_300.html |
The applicable data retention statutes will be provided by the Administrator.
| 2.3.1 - PAYMENT PROTECTION (PP) | |
| SS.PP.1 | The BP shall provide proof of compliance with industry security standards required for the payment options provided. |
Example: Compliance with Payment Card Industry Data Security Standards (PCI-DSS) is required for credit and debit card transactions.
SS.PP.2 The BP shall provide its information security policy for how payment security is addressed in these areas:
• Firewalls to protect financial data
• Protection for stored financial data
• Restrictions to financial data, physical or otherwise
• Tracking of access to financial data
• Regularly testing security systems and processes
| 2.3.2 - SYSTEM LEVEL SECURITY (SLS) | |
| SS.SLS.1 | The system shall manage separate tiers of access for personnel, allowing for separation of duties and administrative tasks. Documentation defining the access provided for each tier must be provided to, and approved by, the Administrator. |
| SS.SLS.2 | The BP systems shall encrypt passwords and log all access attempts to account and log files, compliant with current NIST guidelines. |
| SS.SLS.3 | The BP shall provide a description of the authentication methods used for systems that store personally identifiable information. |
| SS.SLS.4 | The BP shall provide a description of the antivirus and antimalware applications being used, scan frequencies, and the scope of the scans. |
The system shall include mechanisms for detection and notification about potential and realized viral and malware threats.
| SS.SLS.5 | The BP shall provide a description for an incident response process that includes descriptions of triggers, triaging of the incident, notification steps and monitoring steps. |
| SS.SLS.6 | The BP shall provide a description of server management policies utilized for any server related to RUC processing, identifying firewalls, level of encryption (at least AES-256b), and communications. |
| SS.SLS.7 | The BP shall provide a description of backup management policies for testing processes, restore processes, accessibility to back up information, level of encryption (at least AES-256b), and media type used. |
| SS.SLS.8 | The BP shall provide a description of network security such as public/private network separation, encryption (at least AES-256b), and identification of firewalls. |
| SS.SLS.9 | The BP shall provide a description of intrusion detection that includes detection, internal monitoring practices, and incident response. |
| SS.SLS.10 | The BP shall provide its policy for encryption for each level where program data will reside (file, database, disk, etc.). This policy shall include the procedure for preventing unauthorized access. Encryption requirements shall conform to system requirement ID SS.RDM.2. |
| SS.SLS.11 | The BP shall provide its policy for IT system lifecycle management, which shall include, but not be limited to, the change control process (authorization through implementation), security patch process, and ongoing maintenance of updates. Lifecycle management activities shall occur throughout the system development lifecycle including design, acquisition, implementation, configuration, testing, maintenance, and replacement of system components. |
| SS.SLS.12 | The BP shall provide its policy for remote access that includes the specific uses of remote access to program data, authentication method(s), encryption used, mobile device policy, and security measures. |
| SS.SLS.13 | The BP shall provide its policy for wireless management that includes the specific uses of wireless access to program data, encryption used, guest/non-guest access levels, and incident response. Also, if the BP uses industry supported access standards 802.11, it shall indicate which standard is being employed. (i.e. 802.11a, 802.11b, 802.11e, 802.11g, 802.11i, 802.11n) |
| SS.SLS.14 | The BP shall retain participant account data and account financial information for 6 years. (Statute 166-300-0015 and 166-300-0025), allowing for the exception in Senate Bill 810 (“SB 810”), 2013 Oregon Laws, chapter 781, regarding location and daily metered use data. |
| SS.SLS.15 | The BP shall retain computer system security access logs for 3 years, and other system security records for 3 years after superseded or expired. |
| 2.3.3 - DISASTER RECOVERY (DR) | |
| SS.DR.1 | The BP shall provide a plan that details its process for disaster recovery, including back up and redundancy, in the event that an incident threatens or impacts normal business operations. |
| 2.3.4 - RESTRICTED DATA MANAGEMENT (RDM) | |
| SS.RDM.1 | Transmission of Level 3 data between any subsystems shall be secured, at minimum, in accordance with current NIST guidelines and approved by the Administrator. Current NIST guidelines will be at time of contract signing and throughout contract as guidelines are updated by NIST. Upon notice that NIST guidelines have been updated, the BP shall provide a plan to comply with updated guidelines within 60 business days. |
Level 3 data is any sensitive information intended for limited business use that may be exempt from public disclosure because such disclosure may jeopardize the privacy or security of individuals. Personally Identifiable Information (PII) qualifies as Level 3 data.
| SS.RDM.2 | The BP shall encrypt Level 3 Data at rest with AES-256 bit or stronger. |
| 2.4 - BUSINESS PARTENER PERSONNEL | |
| BPP.1 | The BP shall have all personnel with access to any participant information or travel data vetted by performing a background check that includes: |
a) Social Security Number Validation
b) State Criminal Background Check (encompassing the past 7 years)
c) Federal Criminal Background Check (encompassing the past 7 years)
d) State & National Sex Offender Registry
e) State Records Locator If a U.S. based background check is unavailable, an equivalent background check format shall be provided to the Administrator for review and approval.
| BPP.2 | The Account Manager shall provide a process for Administrator approval that describes how it will verify, to a reasonable extent, the identity of the person contacting the Account Manager prior to releasing account information to them. Examples include Individual PIN or Password verification. |
| BPP.3 | The BP shall define the roles and responsibilities of their operation to provide sufficient assurance of segregation of duties. This shall include and not be limited to the BP’s process for oversight and review. |
| BPP.4 | The Oregon Account Manager (OAM) shall provide Account Management subsystem read-only access to the Administrator subsystem for account and financial details. |
| BPP.5 | The BP shall provide read-only access to the Account Management subsystem pursuant to an audit investigation. |
Access to daily metered use and location information will be restricted for the Administrator based upon limitations set forth in ORS 319.915.
BPP.6 The BP or any entity working with the BP shall not disclose personally identifiable information used or developed for reporting travel data by an enrolled vehicle, or for administrative services related to the collection of per-mile road usage charges to any person except:
• The registered vehicle owner or lessee;
• A financial institution, for the purpose of collecting per-mile road usage charges owed;
• Employees of the Administrator;
• An Administrator approved BP (e.g. certified service provider);
• A contractor for a certified BP, but only to the extent the contractor provides services directly related to the certified BP’s agreement with the Administrator;
• An entity expressly approved by the registered owner or lessee of the subject vehicle to receive the information; or
• A police officer pursuant to a valid court order based on probable cause and issued at the request of a federal, state or local law enforcement agency in an authorized criminal investigation involving a person to whom the requested information pertains.
| 2.5 - SYSTEM REPORTING DEFINITIONS (SRD) | |
| SRD.1 | For purposes of reporting data to the Administrator, the BP shall define a day as 12:00:00 am to 11:59:59 pm UTC. |
| SRD.2 | The BP shall reconcile time zone differences for all data transmissions between components and subsystems. |
| SRD.3 | The BP shall maintain the RUC rate table to be used by all components and subsystems, as specified by the Administrator. |
| SRD.4 | The BP shall support changes to the Rate Table as used within all components and subsystems, as directed by the Administrator. |
| SRD.5 | The BP shall secure the following identification numbers, provided by the Administrator, before assigning an MRO to a participant's vehicle for the purposes of collecting and reporting travel data: |
• AMID – Business Partner Identification Number, to be assigned by the Administrator (as defined in the ICD)
• CertID – Certification Identification Number, to be assigned by the Administrator for each MRO certified for RUC mileage collection (as defined in the ICD)
| SRD.6 | The BP shall destroy the saved mileage messages’ location and daily metered use information, per statute, not later than 30 days after dispute resolution for a single quarterly reporting period, or a noncompliance investigation, whichever is latest. |
| 3.1 - PROGRAM INFORMATION AGREEMENTS (PIA) | |
| PPM.PIA.1 | The BP shall be responsible for communicating and updating published policies related to privacy and data retention, to and for the participants and Administrator. |
| PPM.PIA.2 | RUC program Terms and Conditions from the BP, beyond that provided the Administrator, shall be reviewed by the Administrator before publishing to the public. |
| PPM.PIA.3 | If the BP presents any of its own RUC program terms and conditions, beyond that provided by Administrator, to the participant, the BP shall: |
• Request consent for this separate set of terms and conditions
• Request the consent as its own approval step PPM.PIA.4 If the BP requests the participant to expressly approve an entity to receive their PII, then the BP shall:
• Request this express approval as a separate step
• Provide this express approval request as a unique agreement with separate terms and conditions.
Note: The definition of PII can be found in ORS 319.915[3][a][F].
PPM.PIA.5 The BP shall capture and retain the electronic signatures and agreement information for all required agreements, and provide to the Administrator upon request.
Examples:
• Agreement to Terms and Conditions including the Participant Agreement
• Agreement to Participant PII disclosure, if expressly approved
• Agreement to BP retention of location based and daily metered use data, if consented to.
| PPM.PIA.6 | For the purpose of obtaining the participant eSignature on the Participant Agreement, the BP shall require the participant to type their first and last name, in accordance with the current guidelines for first level of NIST electronic authentication (NIST level 1) and approved by the Administrator. |
| PPM.PIA.7 | The BP, upon Administrator's request, shall have the ability to provide the information related to the executed Participant Agreement and program terms and conditions, including: |
a) Participant Name and VIN
b) Participant Agreement Date/Time Stamp, at time of application submission
c) Participant Program Application
d) Participant Electronic Authorization (eSignature)
e) Version and content of Participant Agreement
f) Version and content of any other Terms & Conditions to which the participant consented at the time of application submission.
This information shall be provided through standard document and information formats (including pdf, MS Excel, MS Word and CSV) as specified by the Administrator.
| PPM.PIA.8 | The BP shall validate that the first and last name of the participant’s eSignature match the first and last name as entered during the enrollment process. |
| PPM.PIA.9 | If the BP requests the participant allow retention of location based and daily metered use data (per ORS 319.915[4][a][B]), then the BP shall request this express approval separate from the Participant Agreement. |
| PPM.PIA.10 | If the BP intends to collect data from the participant and enrolled vehicle beyond the minimum required to calculate road usage charges and related fuel tax credits, the BP shall request the consent from the participant in the BP Terms and Conditions. |
| PPM.PIA.11 | The BP shall present any agreements required by the Administrator in its entirety to the participant. |
| 3.2 - PARTICIPANT ACCOUNTS (PA) | |
| PPM.PA.1 | The BP shall implement processes for enrolling participants, onboarding vehicles, processing participants leaving the program, updating account information, handling incoming inquiries, and distributing MROs (if needed). |
| PPM.PA.2 | The BP shall provide details for Administrator approval, regarding the processes they will use for the capabilities of the online service, including participant enrollment and account access, program and contact information, and secure payment processing. |
| PPM.PA.3 | The BP shall record the initial odometer reading for a vehicle. The BP shall be able to correct their initial odometer reading, as needed. |
| PPM.PA.4 | The BP shall assign a unique MRO of the requested type to each vehicle on the participant's account. |
| PPM.PA.5 | The BP shall allow multiple MRO types under the same account. |
| PPM.PA.6 | The BP shall check the vehicle(s) indicated on the enrollment to ensure it is compatible with the MRO selected by the participant. |
| PPM.PA.7 | The BP shall communicate with their participant when their vehicles are accepted or declined for the program. |
| PPM.PA.8 | The BP shall decline the participant who does not accept the Participant Agreement, and shall not send the enrollment information to the Administrator for approval. |
| PPM.PA.9 | The BP shall require an electronic signature from the participant to submit the enrollment information and acceptance of the Terms and Conditions. |
| PPM.PA.10 | The BP shall capture, retain, and transmit all enrollment information to the Administrator, as defined in the ICD. |
| PPM.PA.11 | The BP shall notify the Administrator of all MRO types, including the MRO configuration information, used in RUC Program operations at program start, and of any changes to MROs and related system components that occur. |
See “MROConfigVersion” code block in section 2.2 and 3.10.1 of the Interface Control Document (ICD) for details.
| PPM.PA.12 | The BP shall advise the participant during the enrollment process if there is a condition which will affect their ability to participate. Examples include: program or MRO requirements, vehicle registration address, etc. |
| PPM.PA.13 | Upon receiving an enrollment from a participant, the BP shall review the vehicle information and determine the highest EPA combined MPG rating for the enrolled vehicle type defined below and report it to the Administrator within the Account and VIN Update message: |
The BP shall use the EPA fuel economy data (published at www.fueleconomy.gov) to determine the EPA combined MPG value for the vehicle. If the combined MPG value is not published by the EPA, the BP shall use the best available source to determine MPG. The BP shall determine MPG based on the following logic:
• If the vehicle is powered by gas, diesel or compressed natural gas (CNG), or is a standard hybrid, use the rounded combined MPG value
• If the vehicle is fully electric-powered or uses tax-exempt fuel, no MPG rating is to be used
• Remaining vehicles are plug-in hybrids, use the rounded combined MPGe (PHEVComb) value.
If the BP is unable to identify a value that meets the requirement, the BP must contact the Administrator for assistance.
PPM.PA.14 The Account Manager shall deliver an email upon receipt of the enrollment application submission containing the following information:
• Statement regarding conditional approval into the OReGO program
• Enrollment Application Date (the date the application was submitted)
• Applicant First and Last Name
• Enrolled Vehicle VIN
| PPM.PA.15 | The Account Manager shall allow account creation and account closure. |
| 3.3 - PERFORMING ACCOUNT UPDATES (PAU) | |
| PPM.PAU.1 | The BP shall perform any applicable adjustments to the accounts, as specified by the Administrator, and shall be transferred to the participant account with no administrative fees or withholdings. |
| PPM.PAU.2 | The BP shall allow the participant to add an unlimited number of qualified vehicles to the account as long as that participant is the enrolled registered owner. |
| PPM.PAU.3 | If a new MRO is needed, the BP shall have a replacement process that associates the new MRO with the vehicle on the account. |
| PPM.PAU.4 | For changes in miles, fuel use, RUC, and fuel tax credit amounts the BP shall adjust the participant account, per the jurisdictional rules where and when the miles were driven. |
| PPM.PAU.5 | The BP shall maintain current fuel efficiency values for all vehicles. The values shall be validated in a quality review process at least once per year and transmit changes to the Administrator. |
| PPM.PAU.6 | The BP shall manage the status of the MRO based on the MRO's ability and authority to report required data for the enrolled vehicle. The BP shall report the status change of the MRO within 48 hours of notification for the status change, as defined in the ICD. |
| PPM.PAU.7 | The BP shall be able to manage the status of the MRO for the vehicle on the account without affecting the VIN status or the account status. |
Example: If the BP is notified that the MRO has been lost, the BP shall be able to deactivate the MRO without discontinuing the vehicle on the participant's account.
| 3.4 - CLOSING RUC ACCOUNTS (CRA) | |
| PPM.CRA.1 | The BP shall terminate the account upon request of the participant. |
| PPM.CRA.2 | The BP shall have the ability to terminate a participant account under the conditions of non-payment or the participant’s violation of any agreements. |
| PPM.CRA.3 | The BP shall provide online account access to the participants, at a minimum displaying RUC related information and financial functions, for an amount of time after account closure, as directed by the Administrator. |
| PPM.CRA.4 | When a vehicle is discontinued from the program, the BP shall change the MRO status to de-activated and stop gathering and reporting travel data. |
| PPM.CRA.5 | When a vehicle is discontinued from the program, the BP shall consider the discontinue date the earliest of the notification date or termination date. |
| 3.5 - ONLINE RUC ACCOUNT SERVICES (OS) | |
| PPM.OS.1 | The BP shall make available a service provided by a software application running online and making its facilities available through the internet via an interface. |
| PPM.OS.2 | The BP online service shall allow new volunteers to sign up to become a participant. |
| PPM.OS.3 | The BP shall work with the Administrator on the design and layout of its online website. |
| PPM.OS.4 | The BP’s online service shall include the Administrator's published program information. The Administrator will provide the program information to the BP. |
| PPM.OS.5 | Mileage reporting options shall be offered to the participant for collection and reporting travel data. |
| PPM.OS.6 | Invoices and statements shall be available through the online service interface to the participant. |
| PPM.OS.7 | The online service shall have contact information for the BP and the Administrator. |
| PPM.OS.8 | The BP shall provide access to the participant to view miles traveled and, if available, fuel consumed through the online service interface. |
| PPM.OS.9 | The BP’s online service shall include a means for the participant to view the charges on the account by Rule ID/SubRule ID. |
| 4.1 - MRO ACCURACY | |
| MRO.ACC.1 | The BP shall validate the MRO accuracy by having a third party perform testing to validate accuracy of miles traveled and fuel consumed +/- 5% of actual. These results shall be provided to the Administrator. |
| 4.2 - RECORD ACCUMULATED MILEAGE TRAVELED (RAMT) | |
| MRO.RAMT.1 | The MRO shall monitor and collect travel data for the vehicle to which it is assigned. |
| MRO.RAMT.2 | The MRO shall collect accumulated distance traveled. |
| MRO.RAMT.3 | The MRO shall store all data sent to the Data Collection subsystem for computing accumulated distance traveled until the data is acknowledged as received by the Data Collection subsystem, even under periods of sustained disruption of service. |
| MRO.RAMT.4 | The MRO shall report data to the Data Collection subsystem consistent with the configured MRO reporting period. |
| MRO.RAMT.5 | The MRO reporting period for each MRO type shall be defined by the BP and consistently configured for all MROs of the same type. |
| MRO.RAMT.6 | Location based MRO shall either contain hardware to determine location or interface with external user-provided wireless devices that contain hardware to determine location. |
| MRO.RAMT.7 | The MRO shall record the distance traveled in the applicable Rule ID/SubRule ID in which the vehicle is traveling. |
See the RUC Rate Table in Appendix C.
| MRO.RAMT.8 | The MRO shall calculate total distance traveled by vehicle per AM reporting period within +/-5% of the actual value. |
| MRO.RAMT.9 | When an MRO is capable of operating with or without location differentiation, the BP shall provide a notification and gain consent from the vehicle owner each time the functionality changes. |
| 4.3 - VEHICLE LOCATION DIFFERENTIATION (VLD) | |
| MRO.VLD.1 | Location based MROs shall be able to determine the location of the vehicle within 26 feet of accuracy of the border between applicable Rule ID/SubRule IDs. |
| MRO.VLD.2 | The system shall provide a means for updating map definitions and data points, as well as the definition of each Rule ID/SubRule ID, when changes are warranted based on business rule definitions. |
| MRO.VLD.3 | The BP must utilize a mapping functionality approved by the Administrator, to differentiate taxable and non-taxable miles. |
| 4.4 - DETERMINE FUEL USAGE (DFU) | |
| MRO.DFU.1 | In vehicles that use fuel as a motive power, if the vehicle interface used by the MRO allows monitoring of, or an estimate of, fuel usage (based on parameters such as MAF or MAP sensor data), the MRO shall record the accumulated fuel used by the vehicle for the applicable Rule ID/SubRule ID. |
| MRO.DFU.2 | If data to calculate estimates of fuel consumption is available, the MRO, or an approach approved by the Administrator, shall calculate estimates of fuel consumption per each AM reporting period within +/-5% of the actual value. |
| 4.5 - RESIST FRAUD AND TAMPERING (RFT) | |
| MRO.RFT.1 | The BP shall have the ability to detect and record unauthorized access (or attempt to access) to the MRO using mechanisms such as encryption keys, hash codes, and/or intrusion prevention systems. |
| MRO.RFT.2 | If the MRO has multiple sources for the same piece of data, it shall verify that the data sources correspond. For example, if an MRO collects vehicle speed from the vehicle data port and location information via GPS, it shall ensure that the speed value from the data port falls within a reasonable tolerance threshold of the speed value derived from the location data. The tolerance threshold parameter requires approval from the Administrator. |
| MRO.RFT.3 | The MRO shall detect and record when its mechanism to accurately collect required travel data has been compromised. For example, when an OBD II device has been disconnected or when a vehicle telematics subscription has been deactivated. |
| MRO.RFT.4 | The MRO shall determine whether or not it is capturing required travel data for the associated vehicle. |
| MRO.RFT.5 | The MRO shall contain a record of the current hardware and software version. Changes to the MRO hardware or software shall be transmitted to the Data Collection subsystem. |
| MRO.RFT.6 | If a location based MRO employs a connection to a third-party device for obtaining location data, it shall authenticate with the device before transmitting the data. |
| 4.6 - SAFE AND SECURE (SS) | |
| MRO.SS.1 | The MRO shall not compromise the operation of any original equipment, (from the manufacturer (OEM)) systems or functionality in a vehicle. |
| MRO.SS.2 | The MRO shall not compromise the safety of the operator or passengers of a vehicle. |
| MRO.SS.3 | Physical and logical connections to the vehicle that are required for collecting travel data shall be restricted to only the minimum required for the purposes of collecting RUC. |
| MRO.SS.4 | The MRO shall be certified to be compliant with Title 47 of the Code of Federal Regulations (CFR) and other applicable FCC regulations. |
| 4.7 - TRANSMIT TRAVEL DATA (TTD) | |
| MRO.TTD.1 | The MRO shall send the accumulated travel data or data sufficient to compute accumulated travel data, to the Data Collection subsystem, according to the configured MRO reporting period. |
| MRO.TTD.2 | The MRO shall send error and event log data to the Data Collection subsystem (as defined in the ICD). |
| MRO.TTD.3 | If the MRO collects data for more than one vehicle, each vehicle’s data shall be delineated when sent to the Data Collection subsystem. |
| MRO.TTD.4 | The MRO shall authenticate with the Data Collection subsystem prior to transmitting data to prevent unauthorized transmissions. |
| 5.1 - RECEIVE DATA FROM MRO (RDM) | |
| DC.RDM.1 | The Data Collection subsystem shall have the ability to facilitate the process of data collection, allowing specific, structured information to be gathered in a systematic fashion. |
| DC.RDM.2 | The Data Collection subsystem shall receive, accept and validate data inputs prior to committing the data to storage. |
| DC.RDM.3 | If the Data Collection subsystem receives data for multiple vehicles, it shall maintain the data from each vehicle separately. |
| DC.RDM.4 | The Data Collection subsystem shall authenticate with the MRO prior to receiving transmitted data to prevent unauthorized transmissions. |
| 5.2 - DIFFERENTIATE TRAVEL DATA (DTD) | |
| DC.DTD.1 | The Data Collection subsystem shall report the miles traveled by the applicable Rule ID/SubRule ID. |
| DC.DTD.2 | The Data Collection subsystem shall compute the fuel usage according to the fuel use method value and report it by the applicable Rule ID/SubRule ID. |
FuelUseMethod as described in the ICD:
• 1 = Actual fuel use expected but not captured, calculated by using EPA
• 2 = Actual fuel use captured and used for calculation
• 3 = Fuel use calculated by using EPA
• 4 = Fuel not taxable
For FuelUseMethod value 1 or 3, use this for the fuel usage calculation:
Count of Miles / EPA combined MGP Rating = Fuel Usage
| 5.3 - CONFIGURABLE PARAMETERS (CP) | |
| DC.CP.1 | The system shall allow for the following configurable parameters at a minimum: |
• Communications address of the Transaction Processor subsystem
• Data Storage period
• Rule ID/SubRule ID mapping
| DC.CP.2 | Data for each vehicle must be reported from the Data Collection subsystem to the Transaction Processor subsystem at least once per quarterly reporting period in the mileage message, as defined by the ICD. |
| 5.4 - HANDLE ERRORS AND EVENTS (HEE) | |
| DC.HEE.1 | The Data Collection subsystem shall have a system uptime of 99.99%. |
| DC.HEE.2 | The Data Collection subsystem shall store and transmit any Disconnect events with MRO Health Code 3 to the Transaction Processor subsystem via the mileage message, and associate any such events with the applicable vehicle and MRO ID. |
Disconnect The DC has received information from the MRO, directly or indirectly, that indicates the MRO is not able to send data to the DC. This is to communicate the discovery by the DC that an MRO cannot report required data.
DC.HEE.3 The Data Collection subsystem shall store and transmit any Reconnect events with MRO Health Code 4 to the Transaction Processor subsystem via the mileage message, and associate any such events with the applicable vehicle and MRO ID.
Reconnect After receiving a disconnect event (defined above), the DC received information, directly or indirectly, that indicates the MRO has re-established the ability to report data to the DC. All Reconnect events must be preceded by a Disconnect event. This is to communicate the resolution of the disconnect event.
DC.HEE.4 The Data Collection subsystem shall store and transmit any reporting for New Vehicle Health Code 5 to the Transaction Processor subsystem via the mileage message, and associate any such events with the applicable vehicle and MRO ID.
New Vehicle The DC received the first indication, directly or indirectly, from the MRO that data is being collected and sent to the DC. This is the activation of the MRO, or the first mileage message received with an MROStatus of 1 (activated).
| 5.5 - CREATE AND SEND MILEAGE MESSAGE (MM) | |
| DC.MM.1 | The mileage message shall be created from the accumulated data received from the MRO and data created in the Data Collection subsystem, and conform to the specifications detailed in the ICD. |
| DC.MM.2 | The mileage message shall reflect all event conditions reported by the MRO and determined by the Data Collection subsystem during the DC reporting period in the mileage message. |
| DC.MM.3 | All mileage messages with travel data shall be transmitted to the Transaction Processor subsystem. |
| DC.MM.4 | The Data Collection subsystem shall ensure that there is no overlap in the date and time between sequential reporting mileage messages. |
| DC.MM.5 | The Data Collection subsystem shall ensure that each acknowledged mileage message sent has a unique Message ID. |
| DC.MM.6 | The Data Collection subsystem shall accept an acknowledgement message from the Transaction Processor subsystem that includes the Message ID of the mileage message received. |
| DC.MM.7 | The Data Collection subsystem shall include travel data for mileage messages that are not acknowledged by the Transaction Processor subsystem with the next scheduled mileage message transmission. |
| DC.MM.8 | For purposes of reporting miles traveled by day, a day shall be defined as 12:00:00 am to 11:59:59 pm UTC. |
| DC.MM.9 | If the distance traveled reported by the MRO is not reported in miles, the Data Collection subsystem shall use the unit of measure reported by the MRO to convert the distance traveled into miles with 99.99% accuracy. |
| 6.1 - RECEIVE MILEAGE MESSAGE (RMM) | |
| TP.RMM.1 | The Transaction Processor subsystem shall have the ability to collect, store, modify and retrieve data transactions from the Data Collection subsystem. |
| TP.RMM.2 | The Transaction Processor subsystem shall have a system uptime of 99.99%. |
| TP.RMM.3 | The Transaction Processor subsystem shall allow predefined structured transactions. |
| TP.RMM.4 | The processing activity for each transaction shall be programmed in advance to support mileage messages. |
| TP.RMM.5 | The Transaction Processor subsystem shall store mileage messages received by the Data Collection subsystem with a sequential unique number. |
| 6.2 - VALIDATE MILEAGE MESSAGE (VMM) | |
| TP.VMM.1 | The Transaction Processor subsystem shall validate the data in the mileage message and report validation errors to the Account Management subsystem and the Data Collection subsystem, as defined in the ICD. |
These validations failures shall be reported as Error Event Codes 100-107 in the ICD.
| TP.VMM.2 | The Transaction Processor subsystem shall validate and send an acknowledgement to the Data Collection subsystem upon receipt of the mileage message. |
| 6.3 - HANDLE ERRORS AND EVENTS (HEE) | |
| TP.HEE.1 | The Transaction Processor subsystem shall record mileage message errors and failures and send a Mileage Message Failure message to the Data Collection subsystem, as specified in the ICD. |
| TP.HEE.2 | The Transaction Processor subsystem shall store any events provided by the Data Collection subsystem and associate any reported events with the applicable vehicle and MRO ID, per the ICD. |
| TP.HEE.3 | The Transaction Processor subsystem shall store any errors detected by validation checks performed, and associate the errors to the applicable vehicle and MRO ID, per the ICD. |
| TP.HEE.4 | The Transaction Processor subsystem shall send errors and events information to the Account Management subsystem. |
| 6.4 - CALCULATIONS ( C ) | |
| TP.C.1 | The processing activity for each transaction shall be programmed in advance for calculating Net RUC Balance. |
| TP.C.2 | The Transaction Processor subsystem shall calculate the RUC for miles driven using the RUC Rate Table and applicable Rule ID/SubRule ID logic provided by the respective participating Administrator. |
Total taxable miles x RUC Rate = Road Usage Charge
| TP.C.3 | The Transaction Processor subsystem shall have the ability store the EPA combined MPG rating to determine the fuel usage. |
| TP.C.4 | If the Transaction Processor subsystem determines that the data received to determine fuel usage is not reliable through reasonableness checks, it shall report Fuel use calculated by using EPA, as directed by the ICD. |
| TP.C.5 | If the Transaction Processor subsystem has a pre-stored FuelUseMethod value compute the fuel usage according to the configuration. |
FuelUseMethod as described in the ICD:
• 1 = Actual fuel use expected but not captured, calculated by using EPA
• 2 = Actual fuel use captured and used for calculation
• 3 = Fuel use calculated by using EPA
• 4 = Fuel not taxable
For FuelUseMethod value 1 or 3, use this for the fuel usage calculation:
Count of Miles / EPA MGP Rating = Fuel Usage TP.C.6 The Transaction Processor subsystem shall calculate the Fuel Tax Credit using the RUC Rate Table and applicable Rule ID/SubRule ID logic provided by the respective participating administrator.
Fuel Usage x Fuel Tax Rate = Fuel Tax Credit Amount TP.C.7 The contractor shall accurately calculate the Net RUC Balance:
Count of Taxable Miles x RUC Rate = RUC (A) Total Taxable Gallons of Fuel Used x Fuel Tax Rate = Fuels Tax Credit (B) Where A + B = Net RUC Balance (C) [with exception, see below] Definitions A: Owed Road Usage Charge Amount B: Fuels Tax Credit Amount (always a credit [negative number]) C: Net Road Usage Charge Balance
The Net Road Usage Charge Balance calculation is:
A + B = C unless C is negative (meaning a credit or refund), then C = zero.
If the Net RUC Balance is less than zero, the Transaction Processing subsystem shall adjust the Net RUC balance to zero.
| TP.C.8 | Fuels tax credits are only to be applied until balance is zero. Refunds for scenarios where participants paid more in fuels tax than in RUC will not be issued. |
| TP.C.9 | The Fuels Tax Credit amount shall be applied during day level RUC calculations. |
| TP.C.10 | The Transaction Processor subsystem shall store the calculated Road Usage Charge, Fuel Tax Credit and Net RUC Balance with the associated mileage message. |
| 6.5 - ROUNDING ( R ) | |
| TP.R.1 | The BP shall round travel data and calculation results as follows, or otherwise as approved by the Administrator: |
• Miles Traveled 0.00 Nearest 1/100 of a mile
• Fuel Usage 0.00 Nearest 1/100 of a gallon
• Road Usage Charge $0.00 Nearest whole cent
• Fuel Tax Credit $0.00 Nearest whole cent
• Net RUC Balance $0.00 Nearest whole cent
| 6.6 - STORAGE (S) | |
| TP.S.1 | The Transaction Processor subsystem shall create at least one unique calculation transaction record associated with each mileage message received. |
| TP.S.2 | The Transaction Processor subsystem shall maintain a sequential calculation transaction log. |
| TP.S.3 | The Transactions Processor subsystem shall store mileage messages, according to the Administrators retention requirements. |
| TP.S.4 | The Transaction Processor subsystem shall store the version of the RUC Rate Table used with each RUC calculation transaction record. |
| 6.7 - SEND DATA (SD) | |
| TP.SD.1 | The Transaction Processor subsystem shall send the travel data by applicable Rule ID/SubRule ID, and the computed Road Usage Charge, Fuel Tax Credit and Net RUC Balance data to the Account Management subsystem. |
| TP.SD.2 | Data for each vehicle must be reported from the Transaction Processor subsystem to the Account Management subsystem at least one per quarterly reporting period. |
| 7.1 - RECEIVE DATA FROM TP (RDT) | |
| AM.RDT.1 | The Account Management subsystem shall have a system uptime of 99.99%. |
| AM.RDT.2 | The Account Management subsystem shall receive and store all mileage messages associated for each vehicle on the participant's account. |
| AM.RDT.3 | The Account Management subsystem shall receive and store travel data by applicable Rule ID/SubRule ID and the computed Road Usage Charge, Fuel Tax Credit and Net RUC Balance data from the Transaction Processor subsystem. |
| AM.RDT.4 | If the Account Management subsystem receives travel data for a vehicle that is not associated to the enrolled MRO, do not apply travel data and computed Road Usage Charge, Fuel Tax Credit and Net RUC Balance to the account. |
| AM.RDT.5 | The Account Management subsystem shall receive and store error and event information from the Transaction Processor subsystem. |
| 7.2 - REPORTING ACCOUNT SETUP AND CLOSURE (ASC) | |
| AM.ASC.1 | The Account Management subsystem shall allow account setup and account closeout. |
| AM.ASC.2 | The Account Management subsystem shall report to the Administrator subsystem all new enrollments and discontinued VINs via the Account and VIN Update message, as defined in the ICD, with a frequency approved by the Administrator. |
| AM.ASC.3 | The Account Management subsystem shall be able to have multiple vehicles associated to a single account. |
| AM.ASC.4 | The Account Management subsystem shall request the reason for account closeout from the participant, and if the participant responds, the Account Management subsystem will include this information in the Account and VIN Update message as specified in the ICD, in real time. |
| AM.ASC.5 | The Account Management subsystem shall allow for participants to re-enroll after account closure, for up to 30 days after final payment or dispute resolution or noncompliance investigation, whichever is latest. |
Account closure is defined as an account with no active vehicles, no account balance, no open disputes or noncompliance investigations.
| AM.ASC.6 | The Account Management subsystem shall allow a participant to create a new account after 30 days post account closure (AM.ASC.5) using the same enrollment details, as defined in the ICD. |
| AM.ASC.7 | The Account Management subsystem shall be able to manage the status of the MRO for the vehicle on the account without affecting the VIN status or the account status. |
| 7.3 - PARTICIPANT ACCOUNTS (PA) | |
| AM.PA.1 | For each participant account, the following information, at a minimum, shall be stored in the Account Management subsystem |
• AM Customer Number
• Payment Records
• Billing Adjustments to Account
For each vehicle on the account:
• Vehicle Identification Number (VIN)
• License Plate
• Fuel Use Method
• EPA Rating
• Enrollment Status
• VIN Status
• Pilot ID Code
• MRO Type
• MRO Status
• MRO Configured Reporting Period
• MRO ID
• MRO Certification Identification Number “CertID”
• MRO Configuration Version Details
• Rule ID/SubRule ID for which travel data was collected
• Mileage messages, up to data retention limit
• Current RUC Due
| AM.PA.2 | The Account Management subsystem shall support maintenance (adding, deleting, and updating) of participant account information. This includes information for each vehicle associated with the account and all information provided by the participant. |
| AM.PA.3 | The Account Management subsystem, outside of new enrollments, shall send an Account and VIN Update message to the administrator only when changes are made to the vehicle or participant information only, as defined in the ICD. The Account and VIN Update message shall only contain VINs for new enrollments and VINs with changes to vehicle or participant data. |
| AM.PA.4 | The Account Management subsystem shall provide a secure online service interface for participants to manage their accounts. |
| AM.PA.5 | The Account Management subsystem shall store each change to account information, with identification of the person or system process making the change, the reason for the change, and previous values of all fields changed. |
| AM.PA.6 | The Account Management subsystem online service interface shall be able to handle a load of 150% of the program participant volume simultaneous hits. |
| AM.PA.7 | The Account Management subsystem shall have the ability to add and store text based comments to the account for the Account Manager to enter comments as necessary to capture details related to the account activities. For example, customer service functions, technical support issues, and escalation and communication documentation. |
| AM.PA.8 | The Account Management's online service interface shall provide participant updated mileage data within 48 hours of the data being sent to the Account Management subsystem. |
| 7.4 - REPORTING DATA (RD) | |
| AM.RD.1 | The Account Management subsystem shall generate and send an Account and VIN Update message to the Administrator as defined in the ICD, with a frequency approved by the Administrator, to report only account or vehicle information that has changed since the last submission. |
| AM.RD.2 | The number of VIN records included in the Account and VIN Update message shall not exceed 500. |
| AM.RD.3 | The Account Management subsystem shall generate and send an Error and Events message to the Administrator as defined in the ICD per reporting frequency: weekly, monthly, and quarterly. |
| AM.RD.4 | The number of VIN records included in the Errors and Events message shall not exceed 250. |
| AM.RD.5 | The Account Management subsystem shall generate and send a VIN Summary message to the Administrator as defined in the ICD, per reporting frequency: weekly, monthly, and quarterly. |
| AM.RD.6 | The number of VIN records included in the VIN Summary message shall not exceed 500. |
| AM.RD.7 | The Account Management subsystem shall generate and send the Mileage and RUC Revenue message to the Administrator as specified in the ICD per reporting frequency: weekly, monthly, and quarterly. |
| AM.RD.8 | The Account Management subsystem shall generate and send a Quarterly Tax Report to the Administrator as defined in the ICD per reporting frequency: quarterly. |
| AM.RD.9 | The BP shall, upon request from the Administrator for compliance investigations, provide all mileage messages for a specified group of VINs (or for all VINs in its database) for a specified range of dates to Administration, subject to data that is retained. |
| AM.RD.10 | The Account Management subsystem shall store the following data elements provided by the Administrator. |
• AMID – Business Partner Identification Number
• CertID – Certification Identification Number AM.RD.11 The Account Management subsystem shall store the reports sent to the Administrator. This includes:
• Errors and Events message
• VIN Summary message
• Mileage and RUC Revenue message
• Account and VIN Update message
| 7.5 - MESSAGE HANDLING (MH) | |
| AM.MH.1 | The Account Manager shall provide adjustment details for any financial and travel data adjustments performed for account holders through the reporting, as detailed in the ICD. |
| AM.MH.2 | The Account Manager shall ensure that reports and payment amounts submitted to the Administrator financial entity shall reconcile with an explanation for any variance. |
| AM.MH.3 | The Account Manager shall work with the Administrator to address any message errors or variances upon discovery. |
| AM.MH.4 | When errors or variances are discovered, regular required reports must be resubmitted in their entirety, until all variances or discrepancies are resolved. |
| AM.MH.5 | The Account Manager shall provide ad hoc reports to the Administrator as requested. |
| AM.MH.6 | The Account Manager subsystem shall define a weekly reporting period as Sunday – Saturday. |
| AM.MH.7 | The Account Manager subsystem shall define a monthly reporting period as full calendar months. |
| AM.MH.8 | The Account Manager subsystem shall define a quarterly reporting period as calendar quarters beginning in January. (Jan-Mar, Apr-Jun, Jul-Sept, Oct-Dec) |
| AM.MH.9 | For the purpose of reporting a specific date and time, the BP shall report in UTC time. |
| AM.MH.10 | The following reports shall be retained per statute(s) provided by the Administrator: |
• VIN Summary message
• Mileage and RUC Revenue message
• Errors and Events message
• Account and VIN Update message
• Quarterly Tax Report
| 7.6 - MAINTENANCE (M) | |
| AM.M.1 | The Account Manager shall monitor and resolve all errors and events reported to and identified by the Account Management subsystem. |
Errors and events subject to this requirement are: DC.HEE.x and TP.HEE.x and includes all those requirements within this naming convention.
| 8.1 - BILL PARTICIPANTS (BP) | |
| AMO.BP.1 | The Account Management subsystem shall generate accurate participant invoices and statements and make them available to the participant. |
| AMO.BP.2 | The Account Management subsystem shall maintain a record of statements generated including the ability to regenerate past statements, as defined by data retention requirements. |
| AMO.BP.3 | The Account Management subsystem shall round the road usage charge (RUC) to the nearest whole cent. |
• For the amount equal to or greater than $0.005, round up to the nearest whole cent.
• For the amount with less than $0.005, round down to the nearest whole cent Example: $0.0524 would be rounded to $0.05
| 8.2 - INVOICE TO PARTICIPANTS (ITP) | |
| AMO.ITP.1 | The Account Management subsystem shall be able to accurately calculate the Road Usage Charges, the Fuel Tax Credit credited to participant vehicle(s), the Net RUC balance, and apply it to the appropriate vehicle on the participants account. |
| AMO.ITP.2 | The Account Manager shall provide a statement for participants that shall display, for each vehicle, at a minimum: |
• Description of the vehicle
• MRO Option
• For each applicable Rule ID/Sub Rule ID, list:
o Taxable Miles o Non-taxable Miles o Amount of RUC o RUC Rate o Fuel usage for taxable miles o Fuel usage for non-taxable miles o Amount of Fuel Tax Credit o Fuel Tax Rate
• Incentives Applied (if applicable)
• Penalties Applied (if applicable)
• Adjustments to the account
| AMO.ITP.3 | The Account Manager will manage inquiries from participants and address any issues with invoice discrepancies, making adjustments, if applicable. |
| AMO.ITP.4 | The Account Manager shall process refunds for overpayments as requested by participants for their invoices. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .