cEMV architecture – Benefits of a federated architecture

Conventional cEMV architecture

This architecture is the one pioneered by Transport for London (TfL), where there is a single back-office and acquirer. There are obvious advantages for capping and journey resolution across operators, but basically, it puts all the control with the back-office provider and that has significant disadvantages for operators who want or need to control their own revenue collection. The architecture also poses challenges when an existing cEMV scheme has to be incorporated.

 

 

 

 

 

 

 

 

 

 

 

Federated cEMV architecture

The federated architecture is better for operators, as they manage their own fare collection equipment, enjoy competitive fare collection equipment supply, run their own (private) fare calculations and get certified by their own (competitively procured) merchant acquirer. This is somewhat different and simpler compared to a brokered architecture where all the individual journeys are shared and priced. Capping, where needed, would be managed by a central clearing house that dealt only with aggregates and not individual journeys. This has the advantage that there is no net settlement or money transfer between back offices to deal with capping. For example, if a passenger had spent £12 gross and the cap was £10, then the £2 capping loss would be allocated against each operator who would only claim from their acquirer the net amount. The customer would have a set of payment card charges that added up to the cap. Operators would agree to the rules for setting the caps for each passenger.

 

 

 

 

 

In some schemes, cross-platform transfer and similar conditions are unavoidable. This leads to two back offices holding each end of one trip. The clearing can also deal with these exceptional cases, where there was a priori a possibility of cross-platform transfer. Clearing will need to deal with tokenised FPANs to match passengers, but that’s for another article!