Universal Ticket Agent

Transit View: Fare Policies and Risks

This page describes how the TAs can utilize UniTiAg services. UniTiAg does not take part in the trip validation process and fare calculation. It only provides OTRBs to the TAs. The TA is free to decide whether a particular card tap should lead to the access granting or declining, and what the fare should be.

LPA Account

Some TA policies may require additional data, not included in the OTRB. In such cases, the TA must keep its proprietary Local Patron Accounts (LPA) and propagate them, at least partially, to the wireless validators.

The policy options and related LPA data are presented in the table below.

Fare PolicyExplanationAdditional LPA DataLPA Data in Wireless ValidatorsComment
Flat fareSingle adult fare, no discounts, concessions, or travel distance dependency.NoneN/ANo fare credit is possible
Distance-based or zone-based fareThe TA charges the max possible fare at the tap-on and refunds at the tap-off if the ride is shorter than the longest one.Last tap-on.NoneThe TA may decide to risk an overdraft at tap-on which may be fully or partially covered by tap-off refund.
Period capsThe TA refunds at the end of the cap period (e.g. day, week, or month).Fare history for the cap period duration.NoneDiscount is applied in form of later refund.
Immediate period capsThe TA stops charging the Rider as soon as the cap is achieved.Fare history for the cap period duration.The same LPA Data as in the TAReasonable for low-value OTRBs.
Transfer discountsThe TA discounts transferring from one route to another within a discount period.Fare history for the discount period duration.NoneDiscount is applied in form of refund.
Immediate transfer discountsThe TA discounts transferring from one route to another within a discount period.Fare history for the transfer period duration.The same LPA Data as in the TAReasonable for low-value OTRBs.
ConcessionThe TA does not charge or discounts the eligible OTR Balances for rides.Concession flags; applicable routes; other data as imposed by concessions policies.The same LPA Data as in the TAFare enforcement and concession eligibility is on the TA. The TA does not report $0 fares.
Children faresThe custodian creates an OTRB for each child, connects it to the custodian’s funding account, and associates the OTRB with the child’s debit, prepaid, or white-label cEMV card.Concession flags; applicable routes; other data as imposed by concessions policies.The same LPA Data as in the TAThe child’s card may even not be eligible for contactless retail purchases.
Fare enforcement and concession eligibility is on the TA.
Unbanked: open loopThe riders associate their OTR Balances with prepaid reloadable open-loop cEMV cards.As per fare options aboveThe same LPA Data as in the TAReloading such cards via retail stores are on the Riders.

Validation Process

Let’s take a closer look at the validation process on the validator level. The following diagram illustrates each step of the process, which we will explain in detail.

Validation flow with step-by-step explanation and overdraft risks discussion is presented below.

Step #Explanations
1Validator’s activity starts with card tap.
2Using a card tap data, the validator looks for the related OTRB in the preloaded OTRB List. If this is a wired validator, the OTRB List is stored in the TA’s computer host. If this is a wireless validator, the OTRB List is preloaded to the validator’s memory.
3If the OTRB List does not have this OTRB, this means that it either does not exist, or exists but has not yet been used with this TA.
4So. the OTRB is not found locally. The validator (through the TA) requests this OTRB from UniTiAg.
5If this OTRB exists in UniTiAg, the TA gets it, usually within several milliseconds. Wireless validator, in rare cases, may not get it fast enough. The TA must setup a timeout rule for such cases.
For example, the timeout can be 500 msec for wired validators, 1 sec for wireless validators at peak time and 2 sec for non-peak time, etc.
6So. the OTRB is found, and the validator knows its amount. Now, the validator needs to determine the fare. Each TA has its own rules for the fare for know Patron. The TA can use its LPA accounts to determine concessions, it can apply discounts, etc.
7-14So, the OTRB does not exists or the response from UniTiAg has not come on time. The validator applies the TA policy for such cases.
The risk associated with the first free ride in the UniTiAg model appears to be similar to that of the classic open-loop model. However, with UniTiAg, such cases occur less frequently and the cost of overdraft recovery is lower.
The TA may setup its local stop-lists to prevent the second tap before the OTRB is created and the overdraft is recovered.
8Further decision is made based on the fare and OTRB amount
10-11If OTRB is not enough, the validator applies the TA policies for this case. The TA has more freedom here than in the classic open-loop case because the likeness of overdraft recovery for the known OTRB is high.
12The access to the transit service is granted. If UniTiAg cannot collect the overdraft from the rider, the TA is liable for the overdraft.
15The access to the transit services is not granted because the TA decides not to take the risk for the unknown OTRB.
16The access to the transit service is granted. If UniTiAg cannot collect the overdraft from the rider, the TA is liable for the overdraft. This risk is higher than the risk for the known OTRB because the rider’s account may not even exists in UniTiAg.