UniTiAg Business Architecture

Let’s take a closer look at the business architecture of UniTiAg. 


Two-Sided Marketplaces

The Two-Sided Marketplace (TSMP) is an entity providing online services to Riders (as shoppers or wallet holders) and TAs (as merchants). In addition to its legacy relationships with shoppers-Riders, the TSMP determines with Riders so called Open-To-Ride Balance (OTRB) and informs UniTiAg about the OTRB status and amount.

The Two-Sided Marketplace does the following:

  • Interacts with its Riders for the purpose of OTRB offering, creation, replenishment, and withdrawals.
  • Collects funds from the Riders to replenish OTRBs by means of CNP and e-commerce acquiring, interacting for the latter purposes with acquirers and payment schemes.
  • Provides the Riders with reports of the fares and fare refunds applied to their OTRBs.
  • Reconciles the TAs for their fare-related services.
  • Collects merchant fees from the TAs.

The TSMP implements the TSMP API to communicate with UniTiAg SaaS.

The TSMP does not communicate with Riders with respect to the fare charges validity and TA fare policies. These disputes are conducted by the TAs via their ticketing systems and patron UIs. 


UniTiAg does the following:

  • Collects from the TAs reports related to the OTRB fare charges and fare refunds, via the TA API.
  • Applies changes to the OTRBs requested by the TSMP via the TSMP API.
  • Aggregates the changes in the OTRBs and proactively synchronizes the OTRBs with the TAs or provide the TAs with fast online access to the OTRB data. The OTRBs essentially comprise the fare charge limits within which the TSMP guarantees reconciliation to the TAsUniTiAg synchronizes with any TA only OTRBs actively used in this TA.
  • Provides the TSMPs with fare charge data for TA reconciliation purposes.
  • Complies with the PCI DSS regulations.

Transit Agency

Transit Agency is a transit operator or an agency representing several transit operators. The TA acts as a merchant from the TSMP’s standpoint.

The TA: 

  • Implements its access (validation) policies and determines:
    • Fare schedules,
    • Transfer discounts,
    • Loyalty discounts,
    • Period passes,
    • Period caps,
  • Maintains unique relations with the riders regarding fare policies and services, 
  • Optionally, maintains unique ABT system with rider profiles comprising ride history, discounts, and concession parameters, 
  • Implements the TA API for OTRBs synchronization, fare charge and refunds reporting. 

The TA is not required to implement any type of acquiring for fare collection purposes. The TA does not need to be PCI DSS compliant unless it decides to keep some sensitive cardholder information (for example, to implement their concession policies).  


Validators belong to their respective TAs and are managed by them through the TAs proprietary APIs. There are two types of validators: 

  • Wireless Validators which are usually installed on transit vehicles. They can also be hand-held devices used to validate trips and collect fares. Such validators require a copy of OTRB list that their TA provides them with and synchronizes periodically. 
  • Wired Validators which are usually installed on railway or subway stations, or in any sites where internet connection is reliable and fast. Such validators do not need their own copies of OTRB lists because they can always access the OTRB data or even get validation decisions fast enough, directly from their TA. 

Next to read

UniTiAg contractual relations with customers

Business Artifacts

Feasibility study