20+ YEARS OF CONTACTLESS SMART CARD SUCCESS

For the last quarter century — since the 1996 launch of outstanding fare payments in Korea — smartcards have reigned supreme. They are quicker than past ticketing systems, offering a better customer experience (CX) and more flexibility than paper tickets — making them more desirable to stakeholders.

However, automated fare collection (AFC) systems deployments are long and costly. In essence, they are complex, distributed IT systems, where years can pass between tendering to operation. This has resulted in a market-driven, turnkey approach as the standard. Leaning toward fully integrated systems, AFC relies on the long-term capability and solidity of a prime supplier — one that fully handles risk, delivery, and integration. For a market lacking standardization, where implementations require bespoke solutions, this is understandable.

THE LIMITS OF A MODEL

To reach full integration objectives, however, suppliers often develop their own system, software, and hardware architecture. They deal with technical tradeoffs, design interfaces, and process implementations based on engineering prowess and available technologies. Moreover, to answer tenders with a cost-effective offer, solutions are often reused from an initial baseline via a cut-and-paste approach, without sufficient funds to improve architecture flexibility and maturity. This is the age of monolithic solutions, where subcomponents are imbricated within a complex integration, with some designed and coded by outsourced contractors, thus relying on externalized skills.

Another limit centers on the provisioning of separate solutions and interoperability. This stands true whether between operators or transport modes. Certainly, we have witnessed successful nationwide interoperable deployments, like in Dubai or the Netherlands, but these are based on common specs and an open architecture scheme, regulated by a central organization. The main issue worldwide, however, is that most contactless smartcard–based AFC systems are heavily siloed. They lack data interoperability, save at the media level, sharing a common fare media with specific, local rules. All this adds to cost and complexity of integration.

CX ENHANCEMENT AS A NORTH STAR

Globally, the day-to-day transportation market is characterized by its huge number of transactions — or “taps” — for entries or exits. Commuting is a societal need and the COVID-19 pandemic has demonstrated that it will never significantly drop, even with the increase in remote working.

With such transaction volume, along with the strong driver of easing daily commuter life with the objective of “merging” it with people’s daily connections to their smartphones, industry players have been pushing two key innovations to replace contactless smart cards:

1. Mobile ticketing — allowing customers to use their smartphone instead of a physical ticket, with varying infrastructure interactions (e.g., barcode, NFC, Bluetooth, or just a simple manual validation via an in-app process).
2. EMV open-loop payment — permitting people to travel and pay with what they have in their pocket, just like they do when purchasing items in stores.

EMV OPEN-LOOP PAYMENT

Strong benefits for PTAs & PTOs

EMV open-loop payment is the acceptance of EMV contactless payment cards to pay for transit fares by tapping on a validator or gate. The tap can be charged with a flat fare at entry or later — for instance, after aggregating several taps and reconstructing the journey. In this case, an ABT back end is needed to process the taps and then trigger authorizations and settlements to the payment gateway.

EMV open-loop payment provides greater flexibility to travelers. It allows travel acceptance with something already in most people’s pockets. No more queuing at machines, worrying about which ticket to buy, and the guarantee to pay the fairest fare. This is of great benefit to visitors or tourists, and even commuters whose travel habits changed due to the pandemic, buying fewer and fewer season tickets.

For the PTA/PTO, EMV open-loop payment reduces media issuance cost, cash handling, and even customer support around fare selection. EMV’s modernity and convenience enhance brand improvement and can even act as an adoption driver for populations previously reluctant to travel on public transport.

Constraints/consequence

To accept EMV payment cards, front-end devices must have EMVCo Level 1 and 2 certifications with the entire system validated at Level 3 per scheme. In addition, the system as a whole must be PCI-DSS certified. For the ticketing industry, it’s been a huge challenge to integrate all these constraints, historically only required for retail payment terminals. But in today’s transit world, offering EMV payment card acceptance and guaranteeing a high level of security are now mandatory steps as well. This means extra costs, with some legacy equipment impossible to retrofit and requiring replacement.

Despite being proven, secure, and widely adopted across the payments industry, the EMV ecosystem is complex for transport agencies to navigate. It has many players, technologies, and specific guidelines to be aware of — and be knowledgeable about. One of EMV acceptance’s major benefits is its reliance on strong standards, organically improving interoperability across the network. For multiple operators or transport modes, being able to compute integrated fares and share data accordingly requires heavier integration.

Deployment of this kind of solution necessitates specific attention be paid to risk management, also known as “first tap liability.” In order to maintain high passenger throughput, fare payment is validated offline and accepted “by default” if the card is not blacklisted. The tap is then forwarded to the back end to request an account verification. If this verification flags an issue with the customer account, the blacklist is updated and pushed to all validators in a timely manner. This relies on a dependable infrastructure. The action allows the card to be blocked by the transit network the next time it appears in a transaction, up until the performance of a successful authorization or settlement, as part of a debt recovery process.

Overall, risk management involves looking at several conditions and tactics, with different criteria. These must be agreed upon between the PTAs/PTOs, payment schemes, and acquiring and issuing banks as part of the liability framework. This process is complex and time-consuming. Moreover, travelers can use the service relatively anonymously, meaning PTAs/PTOs risk losing part of their customer base, along with deploying more complex software to integrate concessions.

MODERNIZATION UNDER CONSTRAINTS

PTAs and PTOs also face the unpleasant situation of heavy expenditure to upgrade existing systems with new technologies, deploying additional systems. Development cycles between legacy and new players don’t match up: often a contract-bound “spec-design-test” waterfall approach for the former and a more Agile approach for the latter, integrating modern technical architecture best practices. This means new features are typically deployed within heterogeneous architectures, with unexpected integration and maintenance costs.

Beyond this, it’s generally accepted that closed-loop fare media — whether physical or digitized — will be around for years. Closed-loop systems safeguard the independence of PTAs/PTOs and offer more flexibility to adjust seasonal tickets. Plus, there’s the need to address inclusivity objectives, since PTAs/PTOs are responsible for populations without smartphones or bank accounts, or those just unwilling to use them for travel. Such groups include children, nonbanking individuals, and the elderly — or those wishing to remain anonymous.

The reality is that even if EMV open-loop payment becomes a strong trend, it must coexist with closed-loop solutions. Thus, there is a need to maximize legacy investment and existing ecosystems. However, running both closed- and open-loop systems often leads to an increase in operations and maintenance costs. To optimize the running of a dual ecosystem, PTAs and PTOs should consider a strategic upgrade — an ABT architecture can help.

ABT BENEFITS

The last decade has seen an accelerating uptake of ABT architecture for AFC system modernization. The rise of EMV open-loop payment has, of course, been a push in building traction. In this context, customers can use a payment card to pay the fare, but the equipment can’t write in the card. Within an ABT architecture, the fare media is used mainly as an identifier, with fares processed in the back end.

Overall, this model provides many benefits, including:

• It removes complexity from the fare media. By just serving as an identifier, the media can be simplified to a strict, secured identifier, or a “token.” Generally, fewer operations require an upgrade in functional capability or in managing functional migrations, as there is no data storage requirement. Instead, a central system manages the entire complexity of data. Only security features that authenticate the fare media remain necessary.
• It increases token choice flexibility. Removing the need to process data systematically embodied inside the fare media means the validation device can smoothly integrate several kinds of sensors and logic (e.g., NFC reader, barcode reader, Bluetooth, UWB protocol, camera). The diversity of identifier or tokens can be introduced without heavy complications on the processing logic. The front-end validation device grants or denies entry based on fare media identification matched to a security list (that denies or accepts). The ABT system can manage several tokens to compute fares, such as transport cards, payment cards, barcode or car license plates, all of which enhance CX and personalized service offering.
• It reduces front-end complexity. By removing a large part of fare media processing, the front-end device is less complex to develop and qualify, with a positive impact on integration and maintenance costs, along with operational efficiency. If an interoperability scheme is set up to specify interfaces between front- and back-end layers, the front end can be procured from a different supplier. This kind of standardization associated to a rigorous certification process reduces the provisioning cost of qualified front-end solutions.
• It improves software upgrade and fare rules management processes. With traditional card-based ticketing architecture, business parameters upgrade can take time. (Picture buses that can only download new parameters via WiFi when at the depot.) This kind of architecture brings a certain level of failure, due to bad coverage or unexpected situations where, for instance, data did not finish downloading in time. Reducing the number of parameters improves reliability. In addition, centralized fare processing facilitates and accelerates parameter updates and also enhances promotional fare capacities.
• It improves capabilities for upgrades and scaling. ABT architecture is massively reliant on data exchange via APIs. This enables infrastructure scaling according to deployed front-end equipment and required workload. Front-end hardware is less of a limitation. This removes constraints for upgrading the processing capability and adding features over time. In addition, sales channels can be managed with a centralized server, improving CX, thanks to omnichannel front-end logic. This connects sales machines, web portals, and mobile applications for greater user comfort.
• Real-time integration of data. An API-oriented architecture means the system can connect to others with greater ease. Fare processing can be enhanced with additional services, like third-party commercial bundles; real-time notifications for better travel information; and journey optimization, including duration times, costs, alternative modes, disruption management, carbon footprint tracking, and more. In addition, it can be useful toward loyalty programs with integrated offers and a best-fare promise. Integration time is also shortened thanks to a single subsystem validation process, instead of integrating and deploying several subsystems. This fosters commercial partnerships, including cross acceptance; media integration with a complex data structure, of course, means added costs for devices, with both hardware and software integration required.

We can see ABT architecture providing great advantages in terms of operational flexibility and technical integration. On top of this, it allows PTAs/PTOs to deploy business logic in the following ways:

• Accepts closed- or open-loop fare media.
• Gives choice between subscriptions or PAY-G (with EMV or stored value).
• Enables choice between prepaid or postpaid, with automated reloading.
• Facilitates integrations with third-party payment systems; for instance, top-up mobility accounts for specific populations (nonbanking, children, elderly).
• Continues to accept cash with specific front-end machines to credit mobility accounts.

Overall, the ABT architecture smoothens CX with a frictionless approach toward a real “tap-and-go” experience. Travelers can use their token of choice, without systematic prepurchase. With increased capabilities to integrate complex logic for concession fares, and fare capping to always get the best fare, ABT can help bring people back to public transport after post-pandemic. 

THE BENEFITS OF MODULARITY

Engaging toward AFC modernization requires an agile, long-term approach to successfully implement a sustainable vision. System architecture modularity is key to achieving an ambitious strategy. Modularization is a strong enabler to manage complexity and meet continuous innovation objectives. Among the benefits of modularity, we highlight the following five:

1. Reusability. Well-designed modules that efficiently tackle a targeted problem are often easily reused in different systems.
2. Testability. Purposeful modules have clear, self-sufficient interfaces, which lowers interdependency with other modules. Such interfaces are used to test, reducing the need for mocks to replace missing third-party modules. Formal tests and automated ones are reused as required, improving regression tests and overall quality.
3. Maintainability. Precisely planned modules and interfaces are easy to understand and maintain because they are designed to integrate a limited number of features. This facilitates integration by third parties as well as the optimization of bug fixing.
4. Refactorability. For large-scale solutions, optimal modules — with loose couplings and targeted features — ease refactoring without compromising stability. This reduces “side effects” and the general impact of modifications or evolutions.
5. Scalability. To face demanding situations in terms of processing, complex deployments come with high-performance solutions. This implies redundancy and ease of maintenance. Well-designed modules can be deployed without weak dependencies, increasing operations’ service level and productivity.

The system architecture must guarantee loose coupling between modules in order to enable new features without jeopardizing existing ones, or ongoing operations or service quality. A reminder: one of the most critical success factors is to base the architecture breakdown reference on operational and end-user needs — not the other way around.

KEY CONSIDERATIONS FOR FUTURE-PROOF ABT SOLUTION

Modernizing a ticketing system toward an ABT solution raises a variety of challenges, from technical integration complexity to support for emerging payment technologies, together with compliance and certification requirements with interoperability standards for mobile and contactless payments. Hereafter, we highlight six key considerations to discuss with solution providers for successful and sustainable ABT migration:

1. Create an interoperability scheme. One of the most important considerations when modernizing a ticketing system is to systematically address interoperability. Establishing a strong framework will challenge suppliers to deliver optimized solutions that meet common interface requirements. Theoretically, this could leverage the capability to create new tender rules by splitting the procurement of equipment and back-end systems between different sources. Moreover, this approach fosters market competition and integration of open standards, provides motivation for innovation, and, finally, offers better value for money with high-qualitative solution providers/vendors.
2. Establish data governance and management. By increasing the exchange of data, the problem of data governance and data management rises. This issue should be addressed by the scheme participant, according to regulations, such as GDPR for privacy protection or open data directives. In addition, this involves data portability for both customers (avoids need to re-enter information, with consent management for sharing between different entities) and operators (allows the capability to export and reinject data into a new system).
3. Assess communication networks. Doing so ensures that the current communications networks, both wired and wireless, adapt to accept near-real-time exchange of data with low latency and high bandwidth (internally between assets of the services providers but also with third parties).
4. Strengthen cybersecurity. The token — or fare media — is the key to transport services. Thus, it is necessary to implement the token with a strong authentication mechanism, like contactless smart cards, to avoid travel rights misuse. With the extensive connection capabilities of ABT systems, there is a strong need to reinforce cybersecurity processes to protect APIs and to obtain associated guarantees from suppliers, along with running periodic process and technical audits.
5. Core functions. At the core of an ABT system, there is a clear change in the processing of customer and travel data. The following are the most important functions to implement (see sidebar on the following page for more details):
   • Customer account management
   • Mobility account management
   • Payments management
   • Risk management
   • Fare rules management and processing
6. Business model for solution acquisition. Modernizing a ticketing system leads to new expenses that need to be compared to current spending and expected performance benefit (ROI). Several common models are possible:
   • Up-front capital investment, with maintenance fees to get a turnkey solution. This often allows for perpetual use of the solution. Platform administration and operations must also be addressed as they are on top of solution costs.
   • Software as a service, where recurring fees are paid to use the solution. Several models exist, such as a monthly subscription based on volume, an initial setup payment with additional transaction fees, and adjusted pricing with volume. Such costs involve the ticketing solution in addition to potential transaction costs for a payment system.
   • Public-private partnerships (PPP), which provide specific-purpose vehicles (SPVs) to fund, design, and operate ticketing systems. This kind of model relies on a deep analysis of the ridership and potential revenue as well as a complex agreement to balance the financing of the revenue collection service.

Whatever the model, there are strong requirements to guarantee data ownership and portability. In any case, a solution based on existing products is typically the best starting point for a quick deployment. One must, however, be sure that the providers’ product can evolve to address specific use cases.

MAAS ARCHITECTURE

CX as main focus

At the core vision of MaaS initiatives, there is a strong drive to facilitate the life of travelers and provide new, user-centric experiences with added-value services. Offering outstanding travel experiences with frictionless journeys — like not worrying about fare product or selection — is key to encourage the use of mass transit and sustainable modes.

Digitization and access to integrated services through mobile apps that facilitate access to information and best travel choices have helped. Moreover, smartphones allow for a single-form factor to match an EMV payment card, a digitized smartcard, or the scanning of a barcode to access a mobility service.

To complement the key technical considerations of ABT systems discussed earlier, three additional key core capabilities must be addressed:

1. Integration of multimodal journey planning — allows customers to easily plan journeys, with relevant services to reach their destination based on preferences (e.g., cost, duration, quality of service, convenience, environmental factors).
2. Booking integration — reinforces service availability throughout the journey and avoids losing time waiting for available transport. Beyond comfort, this reinforces confidence and trust.
3. Provision of real-time information — informs the customer of potential delays or disruptions as well as route changes. This information feed must link to alternative options to reach the destination in case of service failure.

Importantly, a mobile app must not be the end goal per se. It is not an absolute requirement for delivering relevant and integrated mobility service. What is key is making it easy for the user to choose sustainable mobility options. This is encouraged and achieved via bundle offers and personalized recommendations. Depending on fare media and depth of features for the user, a key challenge is to ensure an efficient integration of systems.

Integration models

Providing a frictionless experience to users across modes is associated to the successful integration between technical ticketing systems. Fare media digitization and user interaction are just part of this complex transformation, but the perfect communication between different back ends enables outstanding CX. We identify two main integration models that eventually will have an impact on how MaaS will be deployed:

1. Peer-to-peer integration (see Figure 1), where each participant agrees to one-to-one integration between systems.
   • Pros:
     • Offers the advantage of reactivity by implying only the two considered participants.
     • Requires no commercial middleman.
     • Enables the reselling of fare products and services by a third party.
     • Stimulates MaaS performance with the multiplicity of platforms.
   • Cons:
     • Integration is complicated due to the number of different interfaces when more and more systems are interconnected.
     • All participants must agree one-to-one, increasing workload for business and technical staff.
     • The risk of failure for the service delivery increases as new actors are connected.
     • There is a possible disconnection with MaaS societal goals.
     • In this integration scheme, MaaS services can be offered by a different set of players as long as they successfully negotiate commercial and technical deals to integrate the services of third parties. This model is compatible with what we call an “aggregated liberal MaaS” model (see Arthur D. Little’s Report “Beyond MaaS: How to realize the promise of mobility-as-a-service”).
2. Aggregated integration (see Figure 2), where all participants agree to integrate with the same participant, with its system acting as a hub.
   • Pros:
     • Reduces integration costs for participants (effort mainly undertaken by aggregator).
     • Deals with a single partner per participant, reducing overhead.
     • Harmonizes CX.
     • Stimulates MaaS performance with the multiplicity of platforms.
   • Cons:
     • There is a commercial middleman, potentially increasing operational costs.
     • It strengthens the need for a very reliable system for the aggregator, which could become a single point of failure, preventing thousands from traveling in good conditions in case of breakdown.
     • It increases the dominant position of the aggregator, which has more levers to influence or constrain both users and business partners for its sole benefit.
     • This model is compatible with what we call a “disaggregated open (public) MaaS” model. PTAs and PTOs are natural candidates to act as aggregators, ensuring the cooperation of all mobility stakeholders and modernizing their public transport ticketing to be accessible to third parties.

These two models can be mixed in real context, and there is no unique model to integrate systems depending on participant business size. Such integration can be done at any operational level:

• Between transport modes (city level).
• Between services providers (city level, country level).
• Between transport authorities (regional level, national level).

A pragmatic approach is building on top of underlying subsystems. Depending on legacy assets and incumbent stakeholders, specialized suppliers can manage modules and features. This is true, for instance, for the journey planner, the payment platform, or the booking system. This could be a cost-effective, intermediate step to modernize several systems with a modular approach. This brings the advantage of sharing a common interface, along with economies of scale for the provisioning of service.

Beyond mobility services and technical integration for MaaS, a unified ticketing and payment scheme setup is paramount for greater interoperability. Whatever the integration model, there is a need for participants in a transport scheme to collaborate at all levels, from public authority to service providers, public organizations to private companies. Beyond technical issues, success is met when silos are broken; governance policy is clear; and management of entitlement, payment, and revenue collection are correctly integrated. Regarding funding, financial and tax rules must be well understood and accepted, with liabilities for service delivery as a whole or integrated journeys agreed upon, along with a push for an open, formalized ecosystem to easily onboard new service providers. Only then does a seamless CX, with integrated fare media across modes, public and private, become feasible.

ABT deployment can be a pragmatic step toward the acceleration of virtuous MaaS deployment. If properly framed, it has the ability to strengthen the transport authorities’ position as an enabler of MaaS and increase the attractiveness of “shared mobility systems” (public transport as the backbone + “new mobility” MSPs as the “first and last mile”). ABT deployment increases flexibility and reduces time to market for further integration of mobility partners and will ultimately help position shared mobility systems as a credible alternative to always using individual cars “by default.” All of this benefits the end customers, who will have a simplified customer journey. 

Different paths toward ABT are indeed accessible and must be arbitrated according to a set of decision criteria, where various combinations are unique for each PTA and PTO (each transport system is built upon specific ticketing and payment technologies, which presents its own challenges and needs to integrate across different mobility providers).

The ABT/MaaS transformation requires beforehand to dimension the “size of the prize” (e.g., modal shift, increased traffic and revenues, less auto-solism) in order to allocate effectively financial and human means.

A different set of capabilities are required — from strategic thinking to technical design — to build future-proof transit and mobility experience and payment/ticketing systems.