Addendum-1-BC-21497-B.pdf

Solicitation Name: Campus Card Software Solution

Solicitation Number: BC-21497-B

Page 1 of 12 Addendum #1

DATE: February 16, 2026

TO: All Prospective Bidders cc: Procurement File

FROM: Rosetta Butler

RE: Campus Card Software Solution, # BC-21497-B, ADDENDUM #1

The following amends the above referenced Solicitation documents. Receipt of this addendum must be acknowledged by completing the enclosed “Acknowledgement of Receipt of Addenda” form and submitting it along with your response to the University.

The due date and time for the response to be submitted to the University has been changed to

THURSDAY, FEBRUARY 26, 2026 by 11:59 p.m. (ET) to the issuing office.

A. The following information has been changed on the Key Information Sheet:

a. The deadline for technical proposals has been changed to February 26, 2026 at 11:59 p.m. (ET).

b. The MBE goal is changed to “10% (Note: Only for replacement of physical systems).”

c. The Term of Contract is changed to “Five (5) year base period with two (2) two-year option periods.”

B. The following language has been changed in the solicitation to reflect the change in

MBE goal:

a. Section IV, item J. 1. should now state that the MBE goal is “10% (Note: Only for replacement of physical systems).”

b. Exhibit D, D-1A, Part 1, Total MBC Participation Overall Goal is changed to “(Note:

Only for replacement of physical systems).”

Please submit the Waiver Guidance and Good Faith Efforts Documentation to Support

Waiver Request forms found under Exhibit D of the RFP

C. The following questions were submitted for a response.

1. UMBC states the solution should integrate with existing systems ‘or provide a reasonable replacement.’ For access control specifically (currently integrated with Lenel OnGuard), is replacing the access control platform considered an acceptable ‘reasonable replacement,’ or is UMBC expecting vendors to integrate with OnGuard and keep it in place?

Answer: A new solution shouldn't require any type of infrastructure support. A SaaS solution that integrates with Lenel OnGuard via API is strongly preferred.

Page 2 of 12 Addendum #1

2. Verify that questions that are submitted need to be on company letterhead.

Answer: Yes, all questions submitted should be on company letterhead.

3. If replacement of the access control system is not in scope (or is strongly discouraged), can

UMBC share how it expects proposers to realistically reach the 25% MBE subcontracting goal given that access control is typically a major cost driver.

Answer: The MBE goal has been updated to 10% (NOTE: only for replacement of physical systems).

4. Please clarify how bidder's might be penalized for not meeting the 25% MBE subcontracting goal, both in the evaluation and post contract award.

Answer: The meeting of MBE goals is one piece in the overall evaluation and there is no penalty for not being able to meet this goal.

5. Confirming proposal responsiveness: If an offeror expects to be below the 25% MBE subcontracting goal, is a partial waiver request via Attachment D‑1A Part 2 required with the

Technical Proposal submission to remain responsive?

Answer: Yes.

6. Timing of Good Faith Efforts documentation: Please confirm whether Attachment D‑1C

(Good Faith Efforts Documentation) is required with the initial Technical Proposal, or only within 10 business days after notice of apparent award for waiver requestors.

Answer: Attachment D-1C is needed after notice of award.

7. Counting hardware/supply purchases toward the goal (resellers/distributors): For hardware-heavy components (POS terminals, printers, readers, kiosks), does UMBC consider participation through certified MBE hardware resellers/distributors acceptable toward the goal (assuming the MBE is certified under the appropriate NAICS codes)?

8. 60% “Regular Dealer” credit rule: Can UMBC confirm whether hardware purchased through a certified MBE “regular dealer” is credited using the 60% rule described in the MBE instructions, and whether UMBC expects bidders to apply that rule in D‑1A participation calculations?

Answer: In accordance with MBE Participation Schedule Part 3 (page 41), hardware purchased through a certified MBE regular dealer will receive the credit.

Page 3 of 12 Addendum #1

9. MBE subgoals (if any): Please confirm whether this solicitation has any required MBE subgoals (e.g., African American-owned, Women-owned, etc.), or whether only the overall

25% goal applies.

Answer: There are no sub-goals for this solicitation.

10. Can UMBC please confirm by providing a list of all required exhibits for vendors that will submit an MBE waiver request?

Answer: Exhibits B, D (D-1A or D-1B), E, F, G, H, I, J, K, and N are required with technical proposals. Offerors looking to submit an MBE waiver request should submit Attachment D-

1B, which is included in Exhibit D.

11. Given the large amount of detail needed to formulate a plan and develop a proposal, we would like to request an extension to allow time to digest, formulate a plan, and incorporate

UMBC’s answers into our technical proposal.

Answer: The deadline for Technical Proposals has been updated to Thursday, February 26 at 11:59 p.m. (ET).

12. The RFP is for a ‘Campus Card Solution’ which implies a replacement of CS Gold. Given this, what integration with CS Gold is required? Please confirm this RFP includes the replacement of the existing CS Gold campus card transaction system.

Answer: Yes, the RFP includes the replacement of the existing CS Gold campus card system.

Necessary integrations are outlined in Section D, item 7 of the RFP.

13. Is the reference to ‘Blackboard AD’ actually Microsoft Entra ID (formerly Azure AD)?

Answer: This was a typo and meant to state “...Blackboard, AD” as in “…Blackboard, Active Directory..”

14. Does UMBC use Microsoft Entra ID (formerly Azure AD) for SSO?

Answer: UMBC does not use Entre ID. UMBC uses SAML 2.0.

15. Please confirm whether UMBC expects offerors to replace the current card production software (Instant ID), or whether integration/continued use of Instant ID is desired/acceptable.

Answer: Integration with Instant ID strongly preferred

16. Does UMBC use mobile credentials today?

Answer: UMBC does not currently use mobile credentials.

Page 4 of 12 Addendum #1

17. Apple requires a 100% use case for NFC mobile credential whereby all current card accepting locations support mobile credential. Please provide an inventory

(manufacturer/model) of all door readers and locks and USB readers for non-access use cases so that we can confirm which readers can be upgraded, and which need to be replaced.

Answer: All non-access readers currently on campus outlined in Section D, item 20 of the

RFP.

18. Are we to include the cost required to achieve 100% NFC MIFARE card and mobile credential readiness across all readers and locks, including firmware updates for those readers that can be updated and the cost for new readers for those that are unable to be updated, or will that come after selection?

Answer: No costs should be submitted with the Technical Proposal. The transition to mobile credential can occur at a time after selection. UMBC has the internal structure to support this.

19. NFC Mobile Credentials are priced on a per user per year basis. For our pricing submission, how many annual mobile credential users should be assumed?

Answer: No costs should be submitted with the Technical Proposal.

20. Is the goal NFC wallet credential campus-wide at Go-Live, or a phased approach (i.e., Virtual ID in Phase I, followed by NFC mobile credentials in Phase II)?

Answer: It will be in the future, as a phased approach to start at a time after selection.

21. Please confirm the use case to support student elections.

Answer: Students have inquired about setting up a location where ballots can be cast electronically and results did not need to be manually counted. This is a desirable, but not mandatory, feature.

22. For item “5 - Access Controls” subsequent requirement ‘7. Integration…’ lists Onity as a desired integration. Please confirm which offline lock manufacturer(s) UMBC is referencing for “standalone, offline locks,” and whether this requirement is satisfied by supporting those credential technologies.

Answer: A multi-tech credential with a High Coercivity magnetic stripe will satisfy the current Onity-Integra Offline locks.

Page 5 of 12 Addendum #1

23. For each system listed in item “7 – Integration”, please confirm whether integration is mandatory or informational only (with “reasonable replacement” acceptable).

Answer:

a. PeopleSoft = Mandatory

b. Oracle Micros Simphony = Mandatory (open to replacement in future)

c. Instant ID = Mandatory

d. Missouri Bookstore = Desired

e. Grubhub Campus & Off-Campus Flex = Mandatory

f. Lenel OnGuard = Mandatory

g. StarRez = Highly Desired

h. Ex Libris Alma = Highly Desired

i. Pharos = Mandatory

j. Atrium Connect Photo Upload/Online Deposits = Not Mandatory

k. Transact/Cashnet Payment Interface = Reasonable Replacement Acceptable

l. Quadient = Desired

24. For each listed integration, please clarify whether real-time or batch exchange is required/preferred.

a. PeopleSoft = Real Time

b. Oracle Micros Simphony = Real Time

c. Instant ID = Real Time

d. Missouri Bookstore = Real Time

e. Grubhub Campus & Off-Campus Flex = Real Time

f. Lenel OnGuard = Real Time or Batch Exchange

g. StarRez = Real Time or Batch Exchange

h. Ex Libris Alma = Real Time or Batch Exchange

i. Pharos = Real Time

j. Atrium Connect Photo Upload/Online Deposits = Real Time

k. Transact/Cashnet Payment Interface = Real Time

l. Quadient = Batch Exchange

25. What version of Oracle Micros Simphony is UMBC running (e.g., Simphony 1, Simphony 2 on-prem, Simphony Cloud/SaaS)?

Answer: Simphony Cloud.

26. Does CBORD host Symphony or does UMBC or Compass?

Answer: CBORD.

Page 6 of 12 Addendum #1

27. Is UMBC open to retaining Symphony or is the replacement of Simphony with a new POS a mandatory requirement?

Answer: While UMBC is open to hearing about options, the intent at this time is to only replace the campus card software platform. Replacement of Simphony is not a mandatory requirement.

28. Please confirm the use case for Quadient.

Answer: Mail Service employees currently access CS Gold to locate on-campus addresses for students, and Faculty/Staff department locations. Mail Service employees would prefer this information to be visible within the Quadient system to reduce the time needed to complete deliveries.

29. Please confirm the import/export requirement for Quadient.

Answer: UMBC is open to discussion the options around this.

30. Grubhub Campus and Grubhub Off-Campus Flex are listed as current integrations, which may suggest that integration with Grubhub is required. Elsewhere it lists Grubhub as “not mandatory but highly desired.” For pricing clarity, please confirm whether Grubhub integration should be listed in BASE or OPTIONS pricing.

Answer: Grubhub integration should be included in BASE pricing. Do not include any pricing in the Technical Proposal.

31. For event/activity management/reporting, is integration with case management/student well-being systems (e.g., Title IX / Symplicity Advocate) required or optional?

Answer: This is optional.

32. Specific to IDMS integration, please confirm what construct is used to import/export data

(e.g., automated file, direct database, web service) between each system referenced

(PeopleSoft, CS Gold, Blackboard AD, etc.) and the Retriever Card.

Answer: UMBC’s current identity system involves flat file processing and direct database access. UMBC prefers a web service.

33. Please confirm how UMBC is defining “biographical” in item “12 – Cardholder Account

Management.” Please provide an example of this use case.

Answer: UMBC’s current system utilizes Patron Notes. This system allows operators to input notes regarding activity and transactions on a customer’s account. This provides long-term visibility into a history of this patron’s activity. For example, UMBC records a note each time a patron receives a replacement Retriever Card.

Page 7 of 12 Addendum #1

34. Please confirm whether UMBC currently has ID Service Counter terminals/kiosks in place

(make/model/count), and whether bidders should propose replacement hardware, or integration with existing equipment.

Answer: UMBC does currently have this technology. While this is not mandatory UMBC is interested in available options.

35. The RFP states that the solution must allow card photos to be used in reports. Does UMBC have this capability today? If so, share an example of this use case and an example of this report be shared?

Answer: Yes, CS Gold contains canned reports with photos available. Reports are provided when Ad Hoc requests are received from various departments and campus organizations (ex:

Human Resources Annual Service Awards).

36. Please confirm whether UMBC requires offline mode for event/activity terminals specifically

(and whether offline capability is required for both permanent and handheld devices).

Answer: Yes, this is required.

37. Does UMBC have an equipment checkout system today that tracks inventory (e.g., Fusion)?

Answer: No.

38. Please confirm whether UMBC expects the equipment inventory/checkout capability to be provided as a mandatory scope item.

Answer: This is desired, not mandatory.

39. Is a third-party integrated solution for equipment checkout acceptable?

Page 8 of 12 Addendum #1

40. Does UMBC wish to continue using Micros POS or are bidders to propose a replacement?

Answer: At this time UMBC wishes to continue using Micros POS. Replacement proposals would be considered.

41. Please provide the number of registers and dining hall locations.

Answer: 49 POS + 2 “sidecar” terminals across 23 distinct venues on campus.

42. Other than a single cash drawer and receipt printer, what if any other peripherals are in use including kitchen displays, kitchen printers, digital signage, etc.? This is required to accurately price replacement hardware.

Answer: Do not include any pricing in the Technical Proposal.

a. 8 Kitchen Displays (KDS)

b. 14 kitchen printers

c. 10 barcode/SKU scanners

43. If UMBC supports credit/debit cards at the POS currently, please provide the name of the payment gateway provider and the make/model of the payment pin pads in place.

Answer: UMBC does not currently accept credit cards through the Micros terminals. Credit card terminals are not integrated and may not be on the UMBC network. UMBC would like the to integrate with one card reader.

44. Please confirm what UMBC means by "biometric options" (e.g., device biometric unlock for mobile credential, biometric verification at POS), and whether it is optional or required.

Answer: An example is MorphoWave Readers for dining hall entry. This item is desirable but not required.

45. Please confirm whether the equipment quantities listed represent required replacement counts at go-live, or current-state counts used for evaluation/compatibility planning (with phased replacement acceptable).

Answer: These are current counts that must be operational at go-live. Where integration is not available, replacements will be required.

46. Please confirm whether UMBC intends to retain its current payment gateway/processor for

Micros/POS transactions, or whether offerors may propose a new payment processing solution as part of the POS offering.

Answer: UMBC intends to retain current payment gateway/processor in place for

Micros/POS transactions.

Page 9 of 12 Addendum #1

47. Specific to equipment listed, can UMBC supply drawings to show current locations and proposed new. What is the plan for any new locations and any required electrical or cabling to support?

Answer: Not relevant since this project does not include a replacement of the card access system.

48. Please list the make/model of exterior door readers and interior door locks and what ID card credential is being used (e.g., prox, mag stripe).

49. Please provide the make/model of the door controllers and door readers currently in place.

50. What is the door hardware currently installed (e.g., Assa Abloy, Allegion/Schlage, etc.)?

Answer: Not relevant to the scope of this RFP.

51. What are the current credentials on the One Card (e.g., magstripe, barcode, SEOS, etc.)?

Where are each of these Credentials used on campus currently?

a. Magstripe for all transactional activities (meal swipe, declining balance, activity/attendance)

b. Barcode used at Library for book check out

52. Are there any door hardware schedules or drawings that can help us understand the costs involved in running wire/conduit to these doors?

53. To provide accurate access control pricing we need building and wire layouts of these existing access control points and how many buildings they span

54. Can the wiring from the control panel to the door readers be reused?

Page 10 of 12 Addendum #1

55. What is your current video surveillance system?

Answer: Not relevant to the scope of this RFP.

56. Training is listed as onsite, on-going at contractor's expense. This is very vague.

Expectations need to be quantified. (i.e., Will the campus provide a space for any training?

Expectation of number of classes and size)

Answer: UMBC can provide a space for training and would prefer to adopt the Train the

Trainer method to reduce class sizes. UMBC expects roughly 12-15 people in a class.

57. Specific to POS and Kiosks – what is the expectation of cabling/wiring for this? School to provide or contractor? A drawing showing proposed and existing locations is requested.

Answer: UMBC will handle cabling/wiring. At times, this may require the UMBC Division of

Information Technology to hire a contractor.

58. Can we set up a site walk to review the existing access control footprint?

Answer: A site walk is not needed as UMBC is looking for a software solution, not a physical one.

59. On page 26, section, “L. Execution of Proposals,” the RFP states that proposals must be

“signed in ink.” Please confirm whether a wet (handwritten) signature is required, or if an electronic signature is acceptable.

Answer: An electronic signature is acceptable.

60. Solicitation No. BC-21497-B states that Technical Proposals are to be sent to a designated

Box email address as noted on the Key Information Sheet. However, the bidder portal includes a “submit” button without an apparent location to upload supporting documents, and the pre-proposal meeting indicated that proposals may be emailed to the listed contacts.

Answer: All technical proposals should be submitted to the email address in the Key

Information Sheet.

61. Please confirm whether proposals must be submitted exclusively via the Box email address identified in the RFP

Answer: Proposals must be submitted exclusively via the Box email address provided in the

Key Information Sheet.

62. Please confirm whether submission through the bidder portal is required or supplemental.

Answer: Submissions through the bidder portal will not be accepted.

Page 11 of 12 Addendum #1

63. Please confirm whether emailing proposal contacts is required in addition to the formal submission method.

Answer: Emailing proposal contacts is not required, nor is it a replacement for submitting it to the Box email address.

64. Can UMBC please provide more information regarding the University’s access control goals? Seeking to replace an access control system vs. seeking to integrate card system with existing access control? If you're looking to integrate with an existing system, can you please share the name of that system?

Answer: UMBC isn’t looking to change the campus card access system as part of this project, however, any new system would need to integrate with UMBC’s existing on-premise

Lenel card system. UMBC is currently running software version 8.2.

65. Please describe the functions of both the Atrium and CSGold systems on campus today. How are these systems integrated? Is the intent to replace one or both systems, or is the intention to keep these systems in place?

Answer: Atrium is UMBC’s current online transaction deposit system allowing users to instantly add funds using a credit or debit card to their Retriever Card, check balances of meal plan and declining balance accounts, view transaction history, and upload a photo for their Retriever Card. The system supports credit/debit cards to route funds directly to merchant accounts defined in the system. CS Gold is UMBC’s transaction management system that interfaces with various campus systems, physical hardware, and backend account databases to authenticate users, authorize activities based on permissions, and reconcile financial (meal plan and stored value/credit plan) transactions in real time. Actions occur in real time. Within CS Gold, UMBC’s connection to Atrium is via an established location terminal using an Amazon Web Services IP and it is believed that the current integration could be an API. UMBC desires to have a singular solution that can manage all aspects of card management and production, including online deposits.

66. Regarding the Self Service Card Value Center/Kiosk on page 16 of the RFP, can you please provide details on the use cases regarding these kiosks?

Answer: UMBC is interested in having the ability to issue replacement ID cards when the office is closed. This is a desirable, not required.

END OF ADDENDUM #1, DATED 02/16/26

(Original with enclosures were not mailed)

Page 12 of 12 Addendum #1

SOLICITATION NO.: BC-21497-B

SUBMISSION DUE DATE: THURSDAY, FEBRUARY 26, 2026 at 11:59 p.m. ET

BID FOR: Campus Card Software Solution

NAME OF OFFEROR: ___________________________________________

ACKNOWLEDGEMENT OF RECEIPT OF ADDENDA

The undersigned, hereby acknowledges the receipt of the following addenda:

Addendum No. 1 dated 02/16/26

Addendum No. dated _________

As stated in this Addendum, this form is to be returned with your response.

Signature

Printed Name

Title

Date

END OF FORM