BC-21497-B Campus Card Software Solution.pdf

Solicitation Name: Campus Card Software Solution

Solicitation Number: BC-21497-B

REQUEST FOR PROPOSAL

FOR

CAMPUS CARD SOFTWARE SOLUTION

RFP NUMBER: BC-21497-B

ISSUED: JANUARY 30, 2026

Prospective bidders/offerors are encouraged to regularly visit the University’s Department of Procurement & Strategic

Sourcing website, e-Maryland Marketplace Advantage (eMMA) to ensure receipt of any addenda and other updates related to this solicitation. The links to these resources are provided below:

• UMBC Bid Board - https://procurement.umbc.edu/bid-board/

• eMaryland Marketplace Advantage (eMMA) - https://emma.maryland.gov

ISSUING OFFICE

Department of Procurement & Strategic Sourcing

University of Maryland, Baltimore County

Administration Building, 7th Floor

1000 Hilltop Circle

Baltimore, MD 21250

MINORITY, WOMEN AND SMALL BUSINESSES ARE ENCOURGAGED TO

RESPOND TO THIS SOLICITATION

https://procurement.umbc.edu/bid-board/ https://emma.maryland.gov/

Key Information Sheet & Solicitation Schedule

Request for Proposals Title: Campus Card Software Solution

RFP Issue Date: January 30, 2026

Procurement Officer: Rosetta Butler, CMPO, CPPB

Technical Proposal Due Date & Time:

(Not a Public Bid Opening)

February 23, 2026 at 11:59pm

Technical Proposals are to be sent to: Technic.ubd7yhbosgzhl73s@u.box.com

Price Proposals are to be sent to: Instructions will be provided to shortlisted firms

Pre-Proposal Conference: February 6, 2026 at 10:00am at this link

Questions Due Date & Time: February 13, 2026, at 10:00am

Submit Questions to:

Submitt.6px3pqhd6aj310w4@u.box.com

Oral Presentations Placeholder Date April 14, 2026

Minority Business Enterprise (MBE)

Subcontracting Goal:

25%

Contract Type: Indefinite delivery, indefinite quantity

Term of Contract: Five (5) years base period with two (2) one-year option periods.

The University is committed to ensuring that persons with disabilities have equally effective opportunities to participate in and benefit from the University's programs and services. Persons who may require reasonable ADA accommodations should email the Issuing Office at rbutler2@umbc.edu at least five (5) days prior to any meeting scheduled in connection with this solicitation.

mailto:Technic.ubd7yhbosgzhl73s@u.box.com https://www.google.com/url?q=https://umbc.webex.com/umbc/j.php?MTID%3Dm269638c7a5fe0a1f9d21a3c6bec1e11e&sa=D&source=calendar&ust=1770055546922868&usg=AOvVaw2pa7ffj5Uh6BmnmYOPkX8h mailto:Submitt.6px3pqhd6aj310w4@u.box.com mailto:rbutler2@umbc.edu

NOTICE TO BIDDER/OFFERORS

To help improve the quality of bid and proposal solicitations and to make our procurement process more responsive and "business friendly," we ask that you provide comments and suggestions regarding the enclosed solicitation. Please return your comments with your bid, proposal or "no bid," response, as the case may be. Thank you for your assistance.

Project No.: BC-21497-B

Project Title: Campus Card Software Solution

If you have responded with a “no bid” please indicate the reasons below (check applicable boxes):

Other commitments preclude our participation at this time.

The subject of the solicitation is not something we normally provide.

We are inexperienced in the work/commodities required.

The specifications are either unclear or too restrictive (explain below).

The scope of work is beyond our current capacity.

Doing business with Maryland Government Agencies is simply too complicated (explain below).

We cannot be competitive (explain below).

Time allotted for completion of the bid/proposal response is insufficient.

Start-up time is insufficient.

Bonding/insurance requirements are prohibitive (explain below).

MBE requirements (explain below).

Bid/Proposal requirements (other than specifications or scope) are unreasonable or too risky (explain below)

Prior experience with University contracts were not profitable or otherwise unsatisfactory (explain below).

Payment schedule too slow.

Other:

Explanation:

If you have submitted a bid or proposal, but wish to offer suggestions or express concerns, please use the remarks section below:

Remarks:

Bidder/Offeror Name:

Contact Person:

Signature: Date:

Address:

Email: Phone:

TABLE OF CONTENTS

SECTION I. SPECIFICATIONS/SCOPE OF WORK .....………………...………………………………….. 7

A. BACKGROUND

B. SUMMARY STATEMENT

C. MINIMUM QUALIFICATIONS

D. SPECIFICATIONS/SCOPE OF WORK

SECTION II. EVALUATION PROCEDURE

A. EVALUATION COMMITTEE

B. QUALIFYING PROPOSALS

C. TECHNICAL EVALUATION

D. FINANCIAL EVALUATION

E. DISCUSSIONS - BEST AND FINAL OFFERS

F. EVALUATION CRITERIA

G. FINAL RANKING AND SELECTION

H. DEBRIEFING

SECTION III. INFORMATION REQUIRED IN ALL PROPOSALS

A. ORGANIZATION OF TECHNICAL PROPOSAL SUBMISSION

B. TRANSMITTAL LETTER

C. TECHNICAL PROPOSAL

D. TECHNICAL PROPOSAL CONTENTS

E. BID/PROPOSAL AFFIDAVIT

F. MBE UTILIZATION AFFIDAVIT

G. ADDENDA ACKNOWLEDGMENT FORM

H. CONFLICT OF INTEREST AFFIDAVIT & DISCLOSURE

I. PRIME CONTRACTOR LIST OF CONTRACTORS

SECTION IV. INFORMATION FOR OFFERORS

A. ISSUING OFFICE AND PROCUREMENT OFFICER

B. PRE-PROPOSAL CONFERENCE

C. QUESTIONS AND INQUIRIES

D. INSURANCE

E. PROPOSAL DUE DATE

F. DURATION OF PROPOSAL OFFER

G. PROCUREMENT METHOD

H. BASIS FOR AWARD

I. ALTERNATE PROPOSALS

J. MINORITY BUSINESS ENTERPRISE UTILIZATION

K. LIQUIDATED DAMAGES PROVISION RELATED TO MBE GOAL

SECTION V. GENERAL INFORMATION FOR OFFERORS

A. PURPOSE

B. ADDENDA TO THE RFP

C. PRE-PROPOSAL MODIFICATION OR WITHDRAWAL OF OFFERS

D. CANCELLATION OF SOLICITATION/REJECTION OF ALL PROPOSALS

E. DISCUSSIONS

F. ORAL PRESENTATIONS

G. INCURRED EXPENSES

H. ARREARAGES

I. VERIFICATION OF REGISTRATION AND TAX PAYMENT

J. ECONOMY OF PREPARATION

K. PUBLIC INFORMATION ACT NOTICE

L. EXECUTION OF PROPOSALS

M. DISCREPANCIES, EXPLANATIONS AND CLARIFICATIONS

N. ORDER OF PRECEDENCE

O. REQUIRED CONTRACT PROVISIONS

P. OFFEROR RESPONSIBILITIES

Q. FALSE STATEMENTS

R. PAYMENT TO THE CONTRACTOR; TAXES

S. PRESS RELEASES

T. RECIPROCAL PREFERENCE

U. NON-VISUAL ACCESS

V. INTERGOVERNMENTAL COOPERATIVE PURCHASING

W. PARKING

X. SMOKING

EXHIBITS

Exhibit A PreBid/-Proposal Conference ……………………………….…….……………29

Exhibit B Offeror Information Sheet ……………………………………………………...30

Exhibit C Proposal Price Instructions & Sample Form …………………………………...31

Exhibit D MBE Affidavits and Forms …………………………………………………………….34

• D-1A MBE Utilization and Fair Solicitation Affidavit & MBE Participation Schedule (must

• be submitted with Bid/Proposal)

• D-1B Waiver Guidance

• D-1C Good Faith Efforts Documentation to Support Waiver Request

• D-1D MBE Subcontractor Unavailability Certificate

• D-2 Outreach Efforts Compliance Statement

• D-3A MBE Subcontractor Project Participation Certification

• D-3B MBE Prime Project Participation Certification

• D-4A Prime Contractor Paid/Unpaid MBE Invoice Report

• D-4B MBE Prime Contractor Report

• D-5 Subcontractor Paid/Unpaid MBE Invoice Report

Exhibit E Proposal Affidavit ………………………………………………………………………58

Exhibit F Firm Profile & Experience ……………………………………………………………...63

Exhibit G Reference Checks ……………………………………………………………………….64

Exhibit H Key Personnel …………………………………………………………………………..66

Exhibit I Financial Stability of Bidder/Offeror …………………………………………………...67

Exhibit J Acknowledgement of Receipt of Addenda ……………………………………………..68

Exhibit K Conflict of Interest Affidavit & Disclosure Form ………………………………………69

Exhibit L UMBC Sample Contract ………………………………………………………………..70

Exhibit M Prime Contractor List of all Subcontractors …………………………………………… 81

Exhibit N Non-Disclosure Agreement ……………………………………………………………..82

SECTION I. SPECIFICATIONS/SCOPE OF WORK

A. BACKGROUND

Established in 1966, the University of Maryland, Baltimore County (UMBC) is one of twelve institutions that, along with two regional centers, constitute the University System of Maryland. UMBC is located on 482 acres with 4.2 million gross square feet and only 15 minutes from Baltimore’s Inner Harbor and 30 minutes from

Washington, D.C. and five minutes from BWI Airport.

The University of Maryland, Baltimore County (UMBC) is a dynamic public research university located in

Baltimore County, Maryland, and is a member institution of the University System of Maryland. UMBC is recognized for its strong commitment to academic excellence, innovation, and inclusive excellence, serving a diverse student population across undergraduate, graduate, and professional programs.

B. SUMMARY STATEMENT

The University of Maryland, Baltimore County (UMBC), a constituent institution of the University System of

Maryland and an agency of the State of Maryland (herein referred to as the "University" or "UMBC"), is seeking proposals from qualified vendors to provide a card system that will integrate with existing Student

Information Systems and other software/hardware used for various functions or provide a reasonable replacement. UMBC is prepared to adapt its IDMS integration layer to accommodate the selected solution, provided the offeror’s approach represents a sustainable, standards-based architecture. Offerors should not assume UMBC requires replication of its current integration methods.

This solicitation shall be conducted in accordance with the University System of Maryland (USM) Board Regents

Procurement Policies and Procedures.

C. MINIMUM QUALIFICATIONS

1. The Offeror shall have at least 5 years’ experience providing the requested services and shall provide at least three (3) references from organizations of similar size and scope to the UMBC. These references should demonstrate the Offeror’s experience and successful performance in providing comparable services. Each reference shall include the organization’s name, a brief description of the services provided, the timeframe of the engagement, and contact information (including name, title, phone number, and email address) for the individual who can verify the services rendered.

2. The Offeror shall provide evidence of financial stability (e.g., audited financial statements or Dun & Bradstreet report) to ensure long-term viability.

3. The Offeror shall agree to comply with all applicable University System of Maryland and State of Maryland procurement policies, terms, and conditions.

4. UMBC reserves the right to verify all information provided, as well as to consult any other sources available including any person or persons associated with the references provided or the project cited as a reference.

UMBC also reserves the right to request additional references or contact any known firm associated with the

Offeror, as well as itself even if not provided as a reference by the Offeror. References will be held in the strictest of confidence.

D. SCOPE OF WORK/SPECIFICATIONS

1. The offered Offeror campus card solution shall include the following:

• Unlimited number of users, user types, database types, and database connections;

• Easy-to-use application allows quick access to data, minimizing data services workload;

• Timely and informed data-driven decisions in areas such as Student, Finance, Academics, Institutional

Research, Human Resources, etc.;

• Accessible, updated basic system training, user manuals, and help features;

• Cross-platform functionality (ability to integrate with other systems);

• Secure and scalable applications;

• Central management dashboards;

• Self-service options.

2. Features, Capabilities and Controls

The Campus Card Solution shall allow UMBC to go beyond typical ID card production and operate a “one-card campus” where our constituents only need one card, their official University ID, for all functions. These functions must include, but are not limited to:

• Identification;

• Access control (buildings, classrooms, labs, facilities, transportation vehicles);

• Point-of-Sale and similar terminals;

• Meal and Declining Balance authorization;

• Attendance and Activity tracking;

• Provides a simple, expedient process for ID card production;

• Provides audit trails for all transactions;

• Includes a user-friendly means for reporting;

• Offers a management console that allows permissions to be segmented by user, or user group, to allow for distribution of responsibilities based on need;

• Seamless integration with current Identity Management System (IDMS) which is our middleware for identity management across systems (PeopleSoft, CSGold, Blackboard AD, etc.);

• Standard static reporting with report customization and delivery;

• Dynamic reporting with report customization and delivery;

• Supports single sign-on;

• Ability to configure system functions;

• Smart Card and Mobile credential (iOS and Android) issuance and usage;

• Provides web and mobile device access for user account management is desired but not mandatory;

• Provide a solution to support student elections is desired but not mandatory.

3. The solution must be able to load funds on the card (cash deposits via POS, online credit/debit deposits via web portal and/or mobile app, deposits through the software’s module).

• UMBC must be able to reduce the balance based on the student purchases .

• UMBC must be able to integrate the card data with industry standards systems.

• Students must be able to use the card to access and spend their meal plan “swipes” and declining balance funds.

• Students must be able to use the card to check out library books and materials.

• Students must be able to use the card at pay-for-print stations.

• Students must be able to use the card to access residential halls/rooms, classrooms, labs, and facilities across campus.

• Students must be able to use the card to pay for vending machine purchases.

• Students must be able to show, swipe, and scan the card for entrance to a variety of campus-hosted functions and events.

• Students must be able to use their card to access University transportation.

4. The card must entitle users to privileges including facilities use, access resources (tutoring, checkout equipment, and/or off-campus partners).

5. Access Controls - In the event that communications with the host are lost, the card readers must be able to automatically log transactions in an offline state. It must be able to upload logged transaction information to the host when communications are restored.

• Must provide error messages and diagnostic routines to help system operators troubleshoot problems with or without the assistance of supplier technical support.

• Must be user programmable from the host, or another card reader, as well as using its own keypad.

• Must restrict functions to authorized operators and management.

• Credentials supported by standalone, offline lock manufacturers.

6. System User Interface - the offered campus card solution shall include the following:

• Allow system operators to add, change, and delete cardholders and cardholder information individually and by group (i.e., multiple updates, csv imports, batch files, etc.) as necessary.

• Support multiple and highly configurable plans such as board meal plans, block meal plans, unlimited meal plans, declining balance dollar plans.

• Ability to define rules governing the use plans and restrict spending based on specific criteria.

• Include the option of creating unlimited customer-defined fields.

• Allow the ability to design plans from the host or remote workstations via simple menu choices and without special programming.

• Allow quick views for cardholder history to include transactional data, card production history, and event/attendance data.

• Support the ability to add, delete, and change a cardholder’s access/account/plan both individually and by batch update imports.

• Provide detailed guidelines which walk an administrator through the process of creating or configuring system functions.

• Supports single sign-on.

• Provides the ability to add searchable notes to all cardholder accounts for auditing purposes.

• Ability to add attachments to notes.

7. Integration - IDMS (middleware for identity management across systems) Integration. The solution shall provide methods for integration with IDMS to include the following.

• System must allow for automated transfer of data to and from Identity Management System with little to no end-user/programmer intervention.

• System must demonstrate compatibility with current program integrations and list load times when funds are added and when available for student use, funds must be available within 1 minute or less.

• Current program integrations include but are not limited to: PeopleSoft, Oracle Micros Simphony, Instant

ID, Missouri Bookstore (MBS), Grubhub Campus, Grubhub Off-Campus Flex, Lenel OnGuard, Star Rez, Ex Libris Alma, Pharos, Atrium, Transact/CashNet, Quadient.

• The following integrations are not mandatory but highly desired: Starbucks Connect, Onity, Grub Hub, NuPark, ILLiad, Symplicity Advocate, PantrySoft, and industry-leading companies providing Food

Delivery Robots.

• UMBC is prepared to adapt its IDMS integration layer to accommodate the selected solution, provided the vendor's approach represents a sustainable, standards-based architecture. Offerors should not assume

UMBC requires replication of its current integration methods. Proposals will be evaluated on the modernity, flexibility, and sustainability of proposed integration approaches. Preference will be given to solutions offering well-documented, standards-based APIs that reduce long-term integration maintenance burden.

8. Database Administrative Functionality – the solution must include an option for web-based administrative access to the system without the requirement of installing administrative software on a client machine, which must perform the following routine operations:

• Allow user lookup and modification of basic cardholder information;

• Generate ad-hoc reports and retrieval of stored reports;

• and allow the user to assign, edit/delete cardholder access, and card/credential production.

9. Task/Tool Scheduling - the campus card solution must include the following:

• Tools or tasks that, once designed/configured, can be scheduled to automatically update cardholder accounts and access.

• The ability to set up daily, weekly, and monthly schedules, as well as special schedules for end of semester options.

• The ability to perform these operations without operator intervention.

• The ability to launch tools or tasks ad-hoc, if and when needed.

• Provide detailed error and/or audit logs of jobs completed and data modified.

10. Time Period Definition – the solution must:

• Allow authorized operators/administrators to define time periods and names for accounting and reporting purposes.

• Have the ability to use the time period definitions in creating rules which govern the usage of meal and declining balance plans.

• Have the ability to define time periods to reflect the specific operating schedules of various facilities across campus, desired but not mandatory.

11. Reporting Features – the solution must:

• Generate reports and print them to the host or any remote workstation via screen, printer, or file.

• Produce a full variety of reports for tracking and analyzing demographics of campus card operations.

Types of reports such as access and alarm, activity/attendance, meal and declining balance transactions

(sales, rejections, denials – all transactions), transactional and system errors, system configurations, operator audits, card production, patron and operator information, patron and operator permissions, system health and operations, photo and photo history.

• Support a comprehensive set of pre-designed reports, to include declining balance, charge, and cash reports, plan reports, activity (privilege) reports, management reports, maintenance reports, membership reports, user reports, and historical reports.

• Custom reporting must allow the option to include customer-defined fields.

• Design customized standard report queues to be run at regular intervals (daily, weekly, monthly, and on user-specified occasions) without operator intervention.

• Generate all reports at any time without interrupting the online operation of the campus card system.

• Provide complete real-time information.

• Allow queries from any combination of cardholder information and transactions.

• Allow queries to include data points from integrated systems.

• Allow card photos to be used in reports.

12. Cardholder Account Management – the solution must:

• Be capable of expanding to support all current and future cardholder information in cardholder database.

• Create accounts not tied directly to a patron from the University’s Identity Management System for the purposes of creating guest and other ancillary accounts needed for University programs and business.

• Support an unlimited number of cardholder plans, accounts, and privileges/access rights.

• Support the following types of accounts: board plans, block plans, declining balance/stored value dollars plans.

• Ability to track cardholder accounts by ID.

• Advanced search functions to locate cardholder(s) based on any given cardholder information/data points.

• Settings must allow cardholder account balances to go negative, for selective transactions, (customer-controlled parameter) if uploaded logged transactions exceed the amount in the account.

• Include the ability to use a shadow account for enrichment purposes to track real money separately from incentive money.

• Include the ability to track all cardholder accounts and regulate transfers and rollovers from one account into another.

• Support a variety of privilege types including: permit/deny, incrementing/decrementing values, credit/debit, single/multi-use, attendance, and check-in/out.

• Support the ability to link user-defined groups of privileges to specific plans, cardholders, and groups of cardholders.

• Supports automatic recognition of cardholder plans/privileges during transactions to eliminate the need for manual selection.

• Support the ability to assign, suspend, revoke, and reactivate any privilege or package of privileges.

• Include the ability to authorize users to review up-to-the-minute cardholder biographical, account, and transaction histories from any authorized workstation.

• Cardholders must be able to review their own up-to-the-minute account information through the web interface, app, or from any administrative workstation using their ID card.

13. Components of the Production System – the solution must:

• Supports the following card technologies/media type: magstripe, barcode (Codabar format), Smart Card contactless NFC, Mobile NFC.

• Support Windows, iOS, and Android devices.

• Support entries of cardholder information and digitized images.

• System can expand to accommodate as many cardholders as necessary.

• Software comes with complete detailed documentation.

• Software comes with extensive unlimited online help.

• Support multiple user security/access/privilege levels.

• High coercivity magnetic stripe (track 2) & chip encoding is accomplished automatically during the card production process.

• Open data tracks for encoding credentials from different software solutions.

• Support a direct interface to the campus card system.

• Include recognized (non-proprietary) industry-standard hardware and software.

• Support the production of contactless and mobile credentialing technologies.

• Include scheduled backup of open database.

• Provides an automated, system-generated health and security report.

• Extensive audit/error logs stored automatically for review during troubleshooting.

• Send real-time alerts to designated administrators and/or operators when system outages/errors/issues occur.

• Include an electronic copy of all hardware and software manuals.

• Include new equipment only, used or refurbished must not be accepted.

• Include phone support/help twenty-four (24) hours a day seven (7) days a week three hundred and sixty-five (365) days a year (24/7/365). Include remote database administration and maintenance services.

• Environment redundancy options to increase system reliability by allowing continued operation even when individual components fail.

• Disaster recovery validation - please provide a detailed disaster recovery plan and a test procedure/service for annual validation on the test environment.

14. Event & Activity Management Terminal(s) - the solution must:

• Use industry-standard non-proprietary equipment which is compact and light for easy relocation or is accessible through a web-based application or mobile application.

• Have highly visible multiple line displays capable of clearly indicating the result of an attempted transaction and alerting the operator of an off-line condition or other special event.

• Support direct TCP/IP communications without additional wiring or communications device.

• Provide privilege verification in activity locations (UMBC must be able to assign a default activity to individual card readers so that only a card swipe/tap is required).

• Upon operator inquiry, display cardholder’s photo, name, account/event plan number, card status, activity group, date card was last used, and balances in multiple accounts.

• Allow operators to report lost cards from the card reader to the system host.

• Allow managers to define authorized operators so that no transactions can be run unless an authorized operator has signed in.

• In the event that communications with the host are lost, the card reader must be able to automatically log transactions in an off-line state. It must be able to upload logged transaction information to the host when communications are restored.

• Provide error messages and diagnostic routines to help system operators troubleshoot problems with or without the assistance of supplier technical support.

• Be user programmable from the host, or another card reader, as well as using its own keypad.

• Restrict functions to authorized operators and management.

15. Equipment Inventory System – the solution must provide the following:

• Must provide a method to track and maintain a list of inventory items available for cardholder checkout.

• Must perform equipment checkout from any user workstation, web client, or attended card reader.

• Must support standard equipment reporting through the user interface without requiring additional supplier-required programming.

• Must have the ability to report which items are checked-out by which patron and when they were checked-out.

• Must have the ability to charge for checked-out item.

• Ability to send reminders/alerts to cardholders with an active checked-out item regarding return date and late fee charges.

16. Attendance Tracking – the solution must:

• Have attendance tracking for events and meetings - both permanent, wired devices and portable/handheld units.

• The system must easily provide a log of attendees with date/time stamps.

• Must have data available for daily upload to UMBC’s Identity Management System and/or any other integrate platform if desired.

• Classroom attendance is desired but not mandatory. UMBC is interested in wired and wireless devices located inside classrooms as well as portable/handheld units.

17. ID Service Counter – the solution must:

• Terminals must allow for balance check and deposits to primary stored value account.

• Must have point of sale terminal for sales or replacement cards and other available service charges.

• Tenders accepted must include cash, check, credit/debit cards, and stored value/declining balance tenders on IDs produced by UMBC.

• Must provide extensive sales reports and audit logs.

• Must be able to process and log transactions in an offline state and allow negative balances if necessary.

When connection is restored, transactions must upload from the terminal to database.

• Describe the proposed terminals in detail, including specifications, features and physical dimensions.

Provide details on how the solution will accomplish balance checks, deposits, sales/replacement cards, reports and audit logs, as listed above.

18. Meal Authorization - Terminals/machines/readers to validate and deduct meals from board, unlimited or block-controlled meal plans. The system accommodates meal plans including:

• All you care to eat;

• Meals per week offerings;

• Block (per semester) offerings;

• Meal equivalence.

• Allow for primary stored value account to be used to pay for purchases for goods and services (i.e.

beverage and snack vending machines), and be compatible with vending readers that accept both our stored value account and debit/credit cards for payment.

• Provide details demonstrating how the solution provides each of the requirements above.

• Explain how they are configured and programmed, how devices at the locations verify and deduct meals used, and examples of reports available.

• Present all mobile ordering options available. Please include how students and staff can access their meal and account balances and activity via the web and mobile app.

• Available with credential present and biometric options is desired but not mandatory.

19. Equipment – the awarded Offeror shall provide the following equipment, with industry standard warranty for repair and replacement of equipment of 36 months, and list cost for extended warranty after initial warranty expires:

Three (3) commercial grade ID card printer

• Warranty must include advanced replacement;

• One (1) year supply of printer ribbons and cards for printing;

• Information and cost estimate on ribbon suppliers/costs per card;

• Information on warrantee and service plans.

One (1) commercial grade ID card software

• Including customer support plan.

Three (3) compatible 1080p minimum resolution web cameras.

20. Industry standard, OOTB Terminals/card readers as follows (reader must be compatible with iPad, laptop, mobile devices, etc.):

• Four (4) compact swipe readers capable of processing meal plans, declining balance, and activity transactions (currently using Aero III terminals);

• Fifty (50) POS terminals capable of processing or accommodating any combination of meal plan, declining balance, cash, credit/debit, and activity transactions to support various dining and campus retail operations on campus. Including associated hardware/peripherals including but not limited to cash drawers, customer displays, and receipt printers (currently using Oracle Micros Workstation 6 Series);

• Five (5) Kiosk (self-serve) POS terminals capable of processing or accommodating any combination of meal plan, declining balance, cash, credit/debit, and activity transactions to support various dining and campus retail operations on campus. Including associated hardware/peripherals including but not limited to cash drawers, customer displays, and receipt printers (currently using Oracle Micros Workstation 6

Series);

• Fifty (50) USB powered magnetic stripe readers for self-swipe capabilities to eliminate the need for customers to hand their card to a cashier/clerk (currently using IDTech MiniMag II);

• Two (2) Mobile POS terminals capable of processing or accommodating any combination of meal plan, declining balance, credit/debit, and activity transactions to support various dining and campus retail operations (currently using Oracle Micros Workstation 7 series);

• Six (6) Mobile/Tablet terminals capable of processing stored value/declining balance plans and permit/deny activity transactions. Can be an iOS and Android compatible app downloaded onto UMBC-owned mobile devices rather than a physical terminal. Must be compatible at off-campus locations, on off-campus Wi-Fi networks (currently using variety of Apple iPad generations);

• Thirty (30) swipe readers for permit/deny access to determine ridership eligibility on UMBC Transit vehicles (currently using QuantumPay Bluetooth Card Readers);

• Three (3) swipe readers for print release stations;

• Four (4) swipe reader for permit/deny access to Retriever Activity Center;

• One (1) Campus card database system including production, development, and test environments with redundancy.

• Provide information on customer support plan.

• Provide information on warranty, service plans, and estimated consumables cost.

• Provide information on fixed and mobile reader solutions for settings listed above. Provide details demonstrating how the solution provides each of the components above.

21. Card and Production provide a solution for:

• Physical Card production (printer, camera, software, card system support).

• Virtual access devices (allows for mobile credentials via iOS and Android devices).

• Capability for end-user upload of ID image.

• Photo upload feature must include verification methods such as facial recognition and facial comparison.

• Photo upload feature must allow for the requirement of customer-defined supplementary proof of identity

(ie. Upload photo of driver’s license, passport, etc.). Uploaded proof of identity must be purged once an action (approve/deny) is taken on a submitted photo.

• Provide details on how the solution will provide for physical card production, virtual access on mobile devices, and ability of end users to upload ID image.

22. Point of Sale (POS) Value Added Resellers (VAR)

• Point of Sale System that must be an Off-The-Shelf (OTS) or Out-of-the-Box (OOTB) solution, currently in use at Higher Education Institutions.

• Point of Sale System must be industry standard with the ability to interface with multiple payment processing vendors.

• (E) If offeror provides payment processing solution, provide information on implementation, breakdown and description of all fees associated, and benefits.

• (E) If the offeror provides a payment processing solution, describe what transaction details are provided for each transaction.

23. Payment Acceptance features shall:

• Accept the One-Card provided through the RFP;

• Accept credit cards - accept Visa, Mastercard, Discover, American Express, and rewards cards

• Accept Apple Pay and Google Pay anywhere;

• Accept Cash;

• Use contactless, tap to pay for cards and mobile devices;

• Not include inactivity fees;

• Not include monthly fees when no transactions occur;

• Process refunds;

• Accept coupons, rebate codes and gift cards;

• Custom or itemized refunds for payments directly from your POS system or through the online portal/dashboard.

• Payment protection features must:

o Allow disputes to be entered through an online portal/dashboard and are tracked;

o Systems must monitor payments for suspicious transactions and provide electronic alerts to email or

SMS when fraud is suspected;

o All information entered must be encrypted and submitted to the payment servers securely. The system must meet Level 1 PCI Data Security Standards.

o POS must comply with the Payment Card Industry Data Security Standard (PCI DSS).

o Provide Multi-Factor Authentication support for assigned users;

o Set up MFA verification with the use of the POS system to add a second layer of security.

24. Checkout capabilities shall include:

• Item modifiers: Customize items with add-ons and special requests. Modifiers applied to items will display on receipts.

• Ability to create combo meals and conversational/interactive ordering.

• Allows for multiple tax rates, taxable/non-taxable tenders, and split-transactions.

• Allows for percentage and set amount discounts applicable to items, groups of items, quantities, and specials/limited time offers.

• Ability to route items individually or by group to kitchen display screens and kitchen printers.

• Customizable item grid: Allow admin users to configure the display to provide quick access to frequently used items.

• Categories: Group items together in categories to help organize the item library and fine-tune reports.

• Integrated hardware: Registers without built-in payment readers must wirelessly connect the Terminal to any device running the POS payment reader including a smartphone, iPad, or Android tablet.

• Itemized refunds: Refund specific items from a transaction. The amount being refunded will reflect any applicable taxes and discounts for the selected item(s).

25. Additional POS Order Devices shall include:

• Eight (8) Kitchen Display Screens and associated peripherals for displaying menu items at on-campus dining locations;

• Thirteen (13) Kitchen Printers and associate peripherals to receive and print customer orders at on-campus dining locations;

• Ten (10) Barcode/SKU scanners to support quick checkout without cashiers needing to search for items.

26. Transaction and customer service features shall include:

• Offline Mode: Accept swiped card payments when the internet service is temporarily unavailable. Offline payments are processed automatically when the device regains connectivity and will not expire if unprocessed within 72 hours.

• Receipts: Provide customers with digital (text message or email) and printed receipts. Receipts reflect an itemized breakdown of quantities, discounts, and applicable taxes.

• Custom Screen Design: Ability to customize the layout/appearance of all screens to best fit the business being conducted at each location toggling.

• Decimal quantities: Compatible with any specified unit of measure.

• Customer Directory: A contact management tool for storing customer information.

• Order notes: Ability to add notes to items or custom amounts at the time of sale to minimize future questions or disputes.

• Feedback: Customers can provide feedback through digital receipts in their email.

• Customized receipts, order chits, and kitchen display layout/scheme: Ability to adjust the appearance of customer receipts, kitchen printer chits, and kitchen displays.

• Ability to display messages stored on a cardholder’s account on the POS customer display.

27. The Offeror shall list all POS systems that your company supports as part of your card system, along with any integration licensing costs (initial and ongoing license costs).

28. Explain what your company offers if an accredited VAR for the proposed manufacturer or how your company supports other POS systems.

29. Elaborate on features your company adds to proposed, existing, or other brand hardware for a transaction processing system.

30. Explain how your company employs technicians specializing in proposed, existing, or other brand POS terminal hardware.

31. Explain how your company employs technicians specializing in the proposed, existing, or other brand POS terminal software’s.

32. Explain how your company’s help desk is connected to the POS manufacturer’s help desk so that your company can dispatch hardware-related cases directly to the manufacturer on behalf of the client.

33. Provide a listing of all colleges/universities where your company has successfully performed installations within the last 5 years with the proposed POS hardware.

34. Additional System Applications:

The solution shall:

• Integrate with UMBC’s Identity Management System in real-time.

• Support online photo submission.

• Support ability for 3rd party to add funds to cards through online self-service.

• Integrate with library circulation system.

• Integrate with UMBC’s Identity Management System and allows batch uploads.

• Integrate with industry standard, OOTB POS systems and supports mobile ordering.

• Integrate with third party systems for performance/event ticket purchasing.

• Provide logging of liability release waivers resulting in activity access.

• Fully support mobile readers.

35. Desired Features and Functionality shall:

• Door Access Control: Provides complete and robust access control module/suite

• Allow door access via the presented credential. System requirements:

• Allow for programming of flexible unlocked time zones and the ability for easy immediate lockdown.

• (E) Self Service Card Value Center/Kiosk.

• Supplier supplied machine allows cardholders the ability to deposit cash or credit/debit deposits onto the campus ID card.

• The machine supports an optional card-dispensing functionality for visitors.

• Machine operates twenty-four (24) hours a day, seven (7) days a week.

36. Installation

• Prior to installation, the one-card solution must be remotely installed on a test environment provided by

UMBC. As part of the training session, the provider must work with UMBC technical staff to jointly configure the solution for UMBC's Identity Management System. UMBC requires a test environment, a development environment, and a production environment. The provider consultants must help UMBC staff gain the skills to independently install and configure the system for all environments.

• Detail experience in achieving the above and provide a project plan and timeline.

37. Training

• Prior to delivering the training, the provider must work with the UMBC to identify the appropriate stakeholders and team members for training. These stakeholders typically include staff from the institution’s IT and functional administrative departments, or those staff members identified as part of the product implementation or reporting team. All training must be provided on-site or a mutually agreed upon alternative. UMBC requests training for these select groups in a "train the trainer" model as to provide a transfer of knowledge beyond implementation.

• Administrative/Technical Training

• System administrators must receive configuration and security training, designed to provide product administrators with an understanding of how they must approach installation, configuration, setting up users’ security set-up, data connections and troubleshooting.

• The training must be available at no cost to UMBC.

38. Functional Training

• Functional training, including unlimited online and interactive live training, webinars, downloadable recorded training, written and downloadable documentation, context-based help, and on-site training.

• Functional training is designed to provide functional area expertise in the product as it relates to their responsibilities and needs. This training covers basic use, product navigation, and tips and tricks. The training can be customized to specific audience and needs.

• If applicable, advanced training courses to cover beyond the basics in support of empowering UMBC staff to be as self-sufficient and knowledgeable as possible.

39. Ongoing Training

• Additional training must be available at no additional cost.

40. Support

• Support must include the provision of telephone and online technical support (including but not limited to troubleshooting of system issues, identification of system and data errors, support level escalation) preferred hours from 7:00 a.m. Eastern Time to 9:00 p.m. Eastern Time, Monday through Friday, excluding holidays.

• Identify what technical support for all system issues will be provided, with defined severity levels and time to address and time to resolve for each severity level.

• Provide escalation path in case issues require manual escalation.

41. Additional Technology Requirements

• Must be able to accept data from UMBC’s Identity Management System API, with preference given to direct integration.

• Must provide upgrades to software during length of contract to keep UMBC on most current supported software version.

• Complete Data Security Requirements /PCI Compliance.

• Describe what proposed options are available in the event of a system outage.

42. Implementation

• Describe institutional and vendor roles and responsibilities and time commitments recommended for data transfer and training. Provide a projected timeline or calendar identifying milestones and deliverables.

• Describe your post-implementation customer support model including any priority system to provide for urgent support, hours of operation, location of support services, methods of support (ticket, phone, chat, etc.) and any planned changes to this model.

• Upgrades (system functions and features), updates, and enhancements must be included in the annual support fee, and offeror must detail its protocol for seamlessly rolling out upgrades, updates, and enhancements into the existing system after extensive internal quality assurance testing.

• Provide a transition plan that identifies each step in the process to transition from current state to new platform.

• Describe your approach to cybersecurity and maintaining PCI compliance explaining your approach to cybersecurity and how you manage oversight of any third-party partners you are proposing to include in the solution.

43. Risks and Constraints

• Based on the Scope of Work detailed in this RFP, identify any risks or constraints that you will need to address prior to or during the performance of the Contract, as well as a description of how you will address each one. In addition, please identify the following:

o What challenges you anticipate in providing the services identified in this RFP.

o How you will manage those challenges.

o What assistance you will require, if any, from UMBC.

SECTION II. EVALUATION PROCEDURE

A. EVALUATION COMMITTEE

All technical proposals received by the closing deadline will be evaluated by a committee appointed by the

Procurement Officer. The committee may request additional technical assistance from any source within the

University System of Maryland, state government, or other sources deemed appropriate. Technical and price proposals will be evaluated independently.

B. QUALIFYING PROPOSALS

Proposals shall be initially reviewed for compliance with the solicitation requirements. Failure to comply with solicitation requirements may result in a proposal being classified as not reasonably susceptible of being selected for award. Minor irregularities in proposals that are immaterial or inconsequential in nature may be cured or waived whenever it is determined to be in the University's best interest.

C. TECHNICAL EVALUATION

1. After determining compliance with the RFP’s minimum requirements, the evaluation committee will assess and rank technical merit of each proposal in accordance with the criteria below.

2. At the discretion of the Procurement Officer following recommendation by the evaluation committee, a shortlist of qualified proposals may be established during the technical evaluation. Only shortlisted offerors would continue in the evaluation process; offerors not short-listed shall be so advised.

D. FINANCIAL EVALUATION

Price proposals will be evaluated separately from Technical Proposals. Do not submit price information in the technical proposal. Price Proposals will be requested after a shortlist has been established.

E. DISCUSSIONS - BEST AND FINAL OFFERS

1. The Procurement Officer may invite one or more qualified offerors for oral presentations of their proposals.

Discussions or negotiations may be conducted with qualified offerors. With or without discussions, UMBC may determine the Offeror to be not responsible or the Offeror’s Proposal to be not reasonably susceptible of being selected for award at any time after the initial closing date for receipt of Proposals and prior to Contract award.

2. When in the best interest of the University, the Procurement Officer may request that qualified offerors revise their initial proposals by submitting best and final offers.

F. EVALUATION CRITERIA

1. Technical merit will have greater weight than cost.

2. The technical evaluation criteria are listed below in descending order of importance:

a. Offeror's Technical Response to Requirements

b. Offeror's Capacity and Experience, including References

c. Proposed Management and Project Personnel, including Proposed Subcontractors

d. Exceptions to UMBC Contract Terms and Conditions

G. FINAL RANKING AND SELECTION

Following evaluation of the technical and price proposals, the evaluation committee will recommend to the

Procurement Officer award to the responsible offeror whose proposal is determined to be the most advantageous to the University.

H. DEBRIEFING

Unsuccessful offerors may request a debriefing. If the offeror chooses to do so, the request shall be submitted in writing to the Procurement Officer within ten days after the offeror knew, or should have known its proposal was unsuccessful. Debriefings shall be limited to discussion of the specific offeror's proposal only and shall not include a discussion of a competing offeror's proposal. Debriefings shall be conducted at the earliest feasible time.

SECTION III. INFORMATION REQUIRED IN ALL PROPOSALS

A. ORGANIZATION OF TECHNICAL PROPOSAL SUBMISSION

1. The technical proposal shall be submitted electronically not later than the date and time indicated on the

Key Information Summary Sheet.

2. All other correspondence should be directed to the appropriate procurement representative per the instructions contained in this document. The solicitation name and number shall appear in subject line of email along with your company name.

3. Any attachment, or cumulative attachments, at or exceeding 150MB in size will not be accepted by the

University email system. Zip files will also not be accepted by the University. Bidders are permitted to separate attachments into multiple, but shall be clearly labeled.

4. If product literature and other publications are needed to supplement offeror’s response, include a reference to the document name and page in text, and insert the product literature, etc. following the last section of the response.

B. EXECUTIVE SUMMARY/TRANSMITTAL LETTER

Each technical proposal shall be covered by an executive summary/transmittal letter, prepared on the offeror’s business stationery, signed by an individual who is authorized to bind the firm to all statements, proposed services, and prices offered. Do not include price information in the transmittal letter.

C. TECHNICAL PROPOSAL

1. Ensure that it is page-numbered and prepared in a clear and concise manner that addresses each part of the

RFP. Do not include price information in the technical proposal.

2. Organize the technical proposal in the same sequence as Section I of this RFP, and address each separate item herein, confirming compliance and describing in detail how offeror proposes to meet or exceed each requirement.

D. TECHNICAL PROPOSAL CONTENTS

1. Executive Summary/Transmittal Letter. A brief synopsis that demonstrates offeror’s understanding of the University’s requirements and highlighting offeror’s proposed solution/approach to the project, tax identification number and a statement attesting to all terms and conditions or contract terms that

Offeror is taking exception to.

Executive Summary shall also include a statement identifying those portions of the technical proposal considered confidential, or containing proprietary information or trade secrets as detailed in Section V.K.

2. Technical Proposal. Narrative discussing all objectives and requirements as outlined in…