1. Account Based Ticketing and ITSO Guy Roels OAG, 19/05/2016, Milton Keynes

2. 2 There is an increasing interest in Account Based Ticketing (ABT). It is believed that improving the flexibility of ticketing will lead to better service and experience for the customer. The ITSO Board believes this is an aspect of the future that needs to be considered. This document explores to what extent ABT can be implemented using the current ITSO Specification. It will also consider alternative ABT implementations with a varying degree of impact on the ITSO Specification. Executive Summary

3. Account Based Ticketing is a back office centric form of ticketing. The account is held in the back office and the fare calculation is executed AFTER travel. The customer medium mainly acts as token to identify the individual and reference their details to the account in the ‘back office’. What is ABT?

4. 4 High level requirements for ABT: Identification  any IPE Gap analysis  any IPE with VG Tap Data  0801 message using user defined data elements (see Appendix A  hand-outs) (courtesy of Steve Ramsay) Using current ITSO Specification to implement ABT

5. A scheme can currently implement ABT if: The scheme chooses an ITSO product with Value Groups The POST supports the 0801 message and matches it to the default product specific messages The scheme creates a proprietary specification on how to store tap data in the 0801 message The POST populates the 0801 with the user defined data as per the proprietary specification Using current ITSO Specification to implement ABT

6. 6 The above solution to the ABT requirement lacks elegance and leaves room for improvement. A couple of challenges come to mind: Interoperability: The proprietary specification of the user defined data is not expected to be the same across schemes. The solution could benefit from standardising. ITSO could enable the membership to come up with a best practice and formalise it in the ITSO Specification. The impact could be limited to making amendments in very specific areas. Alternative solutions

7. overhead and complexity creep: Generation of twice the amount of messages (terminal side) Need to store twice the amount of messages (back office side) Need to match messages (back office side) If we want to bypass this, we will need to store all data in the product specific message(s). Introducing a new revision of existing messages most certainly will affect existing implementations of these products. Let’s consider to define a dedicated ABT product with dedicated messages. Alternative solutions

8. 8 This product could be very compact because basically all ABT requires of the product is: an identifier of the product (identification) a transaction sequence number (gap analysis) The tap data requirements are mostly independent of the product and are not stored on the customer medium. This product could/would have dedicated messages benefitting from standardisation; removing the overhead and eliminating the complexity. Alternative solutions

9. Overview

10. 10 Overview

11. Does the OAG want ITSO to further explore this option? (i.e. Is there appetite within the membership to implement this solution?) If the answer would be “yes”, then we would welcome suggestions to refine the tap data requirements. Questions