1-RFI-26-0208 Specifications.docx

CITY OF FORT WORTH - PURCHASING DIVISION AUTHORIZED SIGNATURE AND CONTACT DETAILS

RFP Title:_________________________________________________________

CITY OF FORT WORTH - PURCHASING DIVISION

SPECIFICATIONS

RFI Title: P-Card Commercial Card Compliance Solution

1.0 PURPOSE

The City of Fort Worth (City) is issuing this Request for Information (RFI) as a Sources Sought and market research effort to identify qualified financial institutions capable of providing a Purchasing Card (P-Card) and related payment solutions that support the City’s operational requirements and enhanced automated compliance controls.

2.0 BACKGROUND

The City currently operates a decentralized P-Card program supporting multiple departments and cardholders. The program must continue to support routine low-dollar operational purchases while strengthening enterprise-level compliance controls related to statutory and policy purchasing thresholds.

Certain purchasing limitations under Texas law and City policy are aggregate in nature, meaning compliance must be monitored across multiple cardholders and departments purchasing from the same merchant or supplier.

The City relies heavily on manual monitoring processes and spreadsheet based communications to manage aggregate thresholds. The City seeks solutions capable of automating these controls directly within the P-card program and transaction authorization environment.

3.0 KEY COMPLIANCE NEED

The City has a specific compliance requirement related to aggregate vendor spend where purchases without a contract may not exceed an annual threshold (currently $3,000 per vendor, per fiscal year).

For example:

Multiple cardholders may independently purchase from the same merchant (e.g., national retailers). Once combined spend across all cardholders reaches the applicable annual threshold for that merchant, any additional purchases from that merchant may constitute a violation of City policy and applicable Texas law unless a valid contract exists.

The City requires a solution capable of:

· Tracking cumulative spend by merchant and/or supplier across all cardholders and departments; and

· Preventing, restricting, or routing additional transactions once established thresholds are reached.

· Individual cardholder accounts;

· Department and program hierarchy management;

· Merchant Category Code (MCC) controls;

· Transaction amount limits (single transaction and cycle limits);

· Restricted merchant and MCC blocking;

· Real-time authorization and decline logic;

· Electronic receipt capture and transaction reconciliation;

· Audit and reporting functionality; and

· Integration or export capability for the City’s financial and procurement systems.

4.2 The solution is capable of supporting automated controls for aggregate supplier and merchant spend, including:

· Ability to track cumulative spend by merchant and/or supplier across:

· all cardholders,

· all departments, and

· all cost centers;

· Ability to define time-based thresholds (e.g., fiscal year);

· Ability to configure spend caps for specific merchants or suppliers (e.g., $3,000 annually); and

· Ability to automatically:

· decline transactions, or

· routine transactions for exception review or approval, once aggregate thresholds are met.

· Respondents shall clearly indicate whether these controls:

· can be enforced in real time during transaction authorization; or

· function as post-transaction monitoring controls only.

· Identification of merchants or suppliers associated with active City contracts; and

· Exception handling or rule-based overrides tied to those contracts.

4.4 Because national and regional merchants may appear under varying merchant names or identifiers (Walmart #1234, Walmart Store 5678, WAL-MART TX), respondents should describe:

· How merchant normalization and supplier matching are managed; and

· Whether multiple merchant IDs may be mapped to a single supplier for aggregate tracking purposes.

4.5 The solution should support configurable alerts, dashboards, and compliance notifications, including:

· Notifications when defined thresholds are approaching (e.g., 75%, 90%, and 100%);

· Alerts to program administrators when transactions are declined due to aggregate caps; and

· Audit reports supporting compliance reviews and public records requests.

4.6 Respondents should describe the flexibility of the proposed rules engine, including:

· Ability to configure different aggregate thresholds by:

· merchant,

· supplier,

· department, and

· program type;

· Ability to adjust thresholds annually or by fiscal year; and

· Ability to accommodate future changes to City policy or Texas law without significant redesign or custom development.

5.0 IMPLEMENTATION AND PROGRAM SUPPORT

The City seeks information regarding:

· Implementation timelines;

· Configuration and testing approach for rule-based controls;

· Training for program administrators and cardholders;

· Ongoing program support; and

· Customer service structure.

6.0 DATA, REPORTING, AND AUDIT SUPPORT

Respondents, in their response, should describe reporting and export capabilities related to:

· Aggregate supplier spend;

· Declined and overridden transactions;

· Rule configuration history and audit trails; and

· Cardholder and departmental usage reporting.

· PCI compliance;

· Data security controls;

· System availability and resiliency; and

· Privacy protections applicable to cardholder and transaction data.

8.0 ACCOUNTS PAYABLE AND ERP INTEGRATION

The City currently operates an integrated commercial card and Accounts Payable environment utilizing Oracle PeopleSoft ERP.

The proposed solution must support continued automated integration with the City’s Accounts Payable and financial processing environment, including:

· Automated transmission of P-card transaction data to the ERP system;

· Daily or near-real-time transaction feeds;

· Ability to transmit required accounting attributes, including:

· chartfields,

· cost centers,

· departments,

· funds, and

· project information;

· Automated reconciliation and approval workflows; and

· Audit and financial reporting requirements.

Respondents shall describe:

Whether standard Oracle PeopleSoft integration is available;

Whether a third-party integration provider is required;

Technical integration methods utilized (API, file-based interface, middleware, etc.); and Any limitations on data elements passed to the ERP system.

The City seeks to avoid solutions requiring significant custom development, manual file manipulation, or parallel reconciliation processes.

9.0 PRICING AND COMMERCIAL STRUCTURE

The City currently operates its P-Card program under a no-cost structure in which administration, technology, and support services are primarily funded through merchant interchange revenue.

The City seeks solutions supporting a similar no-cost or revenue-funded model. Respondents shall clearly describe all fees charged to the City, including:

· implementation/setup fees,

· portal or platform fees,

· advanced control or rules engine fees,

· reporting and analytics fees,

· integration/interface fees, and

· ongoing support/account management fees;

Whether advanced compliance or aggregate spend control functionality is included within the base solution or offered as optional modules; and Any minimum transaction volume, rebate, or spend thresholds associated with pricing.

Respondents should additionally describe:

· Eligibility for rebates, revenue sharing, or other incentives; and

· Methodology used to calculate and distribute rebate or revenue-sharing payments.

The City intends to review both functional capability and long-term sustainability of the proposed commercial structure.

1. Company overview and experience providing municipal or public-sector commercial card programs;

2. Description of existing clients utilizing similar aggregate vendor or statutory spend controls;

3. Detailed explanation of how the proposed solution addresses the aggregate vendor spend requirement described in Section 4.2;

4. Description of real-time authorization versus post-transaction monitoring capabilities;

5. Detailed explanation of how merchant normalization and supplier match are managed and whether multiple merchant IDs may be mapped to a single supplier for aggregate tracking purposes;

6. High-level architecture of the proposed solution;

7. Implementation and onboarding approach;

8. Pricing structure;

9. Identification of known limitations or constraints; and

10. Additional recommendations or innovations.

Important Clarification - The City is specifically interested in solutions that reduce or eliminate reliance on manual tracking mechanisms for enforcing aggregate statutory and policy thresholds.

11.0 DISCLAIMER

This RFI/Sources Sought notice is issued solely for information and planning purposes and does not constitute a solicitation, contract, or commitment by the City of Fort Worth to issue a future procurement.

The City reserves the right to use information obtained through this process in the development of future solicitations.

image1.jpeg