Product Clearing & Settlement Phase 2

HIGH LEVEL DESIGN

File Name: 0e6ee15de29be132b522334be3c74d7a.docx

Version: V0.6

Date: 21-09-2011

Status: Draft

Author: Joop Akkerman

Editor: Laurens van Piggelen

Alle rechten voorbehouden De lezer ontvangt dit document onder de uitdrukkelijke voorwaarde dat dit document vertrouwelijk behandeld zal worden en van de inhoud geen gebruik zal worden gemaakt zonder voorafgaande schriftelijke toestemming van TLS B.V. Bovendien is het de lezer niet toegestaan dit document op enigerlei wijze aan derden ter beschikking stellen zonder voorafgaande schriftelijke toestemming van TLS B.V.

HANDELSMERKEN Alle in dit document genoemde handelsmerken zijn eigendom van de rechthebbenden.

30e6ee15de29be132b522334be3c74d7a.docx HLD Product Settlement Phase 2

Document History

Author Date Changes Version Joop Akkerman 25-07-2011 First draft v 0.1 Joop Akkerman 17-08-2011 Remarks test team and Christian v 0.2 Senly incorporated Laurens van Piggelen 01-09-2011 Further clarification and elaboration v 0.3 Laurens van Piggelen 07-09-2011 Updates based on internal reviews v 0.4 Laurens van Piggelen 16-09-2011 Complete rewrite of the calculation v 0.5 method Laurens van Piggelen 21-06-2011 Clarification on calculation method V 0.6 and listing of variations of the happy flow

References

Reference Document Name Version Document Date [R1] Manual of Rules and Regulations 3.1 3 december 2010 (Handboek Regels en Procedures, HRP) [R2] SDOA .. [R3] Allocatie van Reisproducten n/a 29-06-2011 [R4] Functionele specs “Altijd Korting” n/a 17 juni 2011 [R5] CR Product Settlement 1.0 20100811

Contents

1. Introduction Currently the settlement of sales of interoperable products is performed in accordance with the WROOV rules. As the WROOV ceases to exist per 01-01-2012, an OV-Chipkaart based alternative needs to be developed, in which the product sales are settled in accordance with the rules as defined by the LPR1. These rules have recently been approved by the DOC2.

In order to obtain some experience with product settlement a Proof of Concept was developed in the second half of 2010. As no formal LPR was in place at that time, this PoC was based on a number of assumed settlement rules. This PoC is also referred to as Product Settlement Phase 1 and is described in [R5].

With a formal LPR in place, the phase 1 solution has to be adapted to the settlement rules as set by the LPR for the “Altijd Korting” product ([3],[4]).

1 Management Summary [Describes the conclusions and summary of this High Level Design. This may include a description of the current situation and / or problem, or a description of the business case.]

2 Design Scope The scope of this document is limited to the settlement of the “Altijd Korting” discount product (and similar product complying with the same settlement rules). The design assumes the concession ID in the usage transactions is filled and contains a valid value. The concession ID is used in reporting.

3 Objectives The purpose of this HLD is to describe the solution of phase 2 of Product Settlement in relation to the solution for phase 1

1 LPR = Landelijke Product Regisseur (Nationwide Product Owner) 2 DOC = Directeurenoverleg OV-chipkaart (Director’s meeting OV-chipkaart

2. High Level (Business) Requirements In this chapter the high level business requirements are described. As phase 2 is an extension to phase 1, in the first paragraph a description is given of the phase 1 solution. The second paragraph describes the business requirements for phase 2, which are clarified by means of examples.

4 Requirements for phase 1 The pre-phase 1 version of the CCHS contains a mechanism to apportion the product sales based on a set of static apportionment keys. Lacking in the CCHS was a mechanism to calculate apportionment keys based on actual usage per PTO. This mechanism was developed as part of phase 1. On the first day of the month CCHS calculates advisory apportionment keys for the preceding month. These keys are not automatically used for apportionment; it is up to an operator to transfer the advisory keys to the current keys. Product sales are apportioned on the business day following the sale using the current apportionment key (pre-calculation). In this way the PTO’s can obtain their money as soon as possible. However, during the actual usage of the product, it may appear that the keys used during the pre-calculation are not completely correct. In order to compensate for this a post-calculation is done on day 8 of every month (to accommodate for late transactions) for all expired/refunded product-instances (so product-instances on which no more usage transactions will be generated) using the apportionment keys calculated based on the actual usage. Per PTO the differences between pre- and post-calculation will be credited/debited3.

5 Differences between phase 1 and 2 In phase 2 a different approach is followed for product settlement. The table below gives an overview of the main differences between the phase 1 en phase 2 solutions; the phase 2 solution is specified in more detail in the next paragraph.

Characteristic Phase 1 Phase 2 Granularity Per PTO Per card Settlement approach Pre & post-calculation Post-calculation,  Month product: monthly  Yearly product: quarterly Key calculation Per product per PTO Per product, per card and per concession Settlement payment None By means of ClieOp(s) Reporting Consolidated only Consolidated and per PTO Table 1: Differences between phase 1 and 2

3 As phase 1 was a PoC only, no ClieOp files were generated nor payments performed.

6 Requirements for phase 2 In the following table the requirements for phase 2 are listed. These requirements are derived from [R3] and from discussions based on [R3].

Req. Id Description Priority Req.PS2 Settlement data will be gathered per product, per card and per concession. H . Req.PS2 Settlement will be done per PTO, reporting will be done per concession. H . Req.PS2 The phase 2 solution supersedes the phase 1 solution. M . Req.PS2 Transactions will be settled based on the e-purse value usage ratio. Note: the values in H . e-purse check-out transactions will be used, as the final price calculation takes places during check-out. Cross-border transactions are ignored. Req.PS2 TLS creates a dedicated bank account for the float of product settlement. Note: The H . value of all to be apportioned product sales is to be transferred from the retailers to this bank account. Req.PS2 The float on the dedicated bank account should not be too high but adequate to M . perform the settlement.4 Req.PS2 Unused yearly products will be apportioned based on H . Req.PS2 Unused monthly products will be apportioned based on H . Req.PS2 Settlement payment and reporting will be done on a daily basis. A ClieOp will be H . generated to perform payment. Req.PS2 Settlement for a specific product instance is done a configurable number of days after H . expiration (or quarter year passing for yearly products) to allow for late transactions. Req.PS2 Settlement for a specific product instance is not done for as long as the product sales H . amount is unknown (i.e. the product sales transaction has not been received). 62 days after the product sale date (when no product sales transaction will be processed by CCHS anymore) the impossibility of settling a product instance will be reported to the LPR. This applies to both monthly and yearly products. Req.PS2 Settlement is done afterwards, for monthly products after product expiry, for yearly H . product per fully expired validity quarter. Req.PS2 Refunds will be settled as negative sales. H . Req.PS2 Discount will be nationwide uniform. M . Req.PS2 For each product instance to be settled, the CO will calculate apportionment keys based H . on actual usage of the product instance. Req.PS2 The concession where the trip took place is based on the concession in the check-out H . transaction, even if the trip took place in multiple concessions. Req.PS2 During the settlement of yearly products, only those products instances are settled for H . which a quarter year has fully expired, measured from the validity date of the product. The amount to be settled for a quarter equals a quarter of the sale amount. Req.PS2 The participants will only have access to the reports intended for them. H . Req.PS2 For the Clearing Operator a report is generated that shows on a monthly basis the H . various sales amounts per product and the number of corresponding sales transactions.5 Req.PS2 The historic key values (both calculated and actually used) are kept/archived. M .

4 This will be done outside the system. The requirement has to be made smart. 5 This is to check if a product has been sold at other amounts (e.g. discounts) than the agreed amount and how often this occurred.

80e6ee15de29be132b522334be3c74d7a.docx HLD Product Settlement Phase 2 Req. Id Description Priority Req.PS2 Fees are not taken into account and will be settled outside of this process. H . Req.PS2 The sales amount as reported in a sales transaction is used for both settlement at time H . of the sale and post settlement. Req.PS2 As long as a products instance’s sales amount is not available at the moment of H . settlement (no product sales transaction has been received), the product instance is excluded from the settlement process. Once the sales amount becomes available it is included (product sales transaction has been received). Req.PS2 If no sales transaction has been received by CCHS 63 days after the product instance was H . sold, settlement will not be possible anymore and the inability to settle this product instance is reported. Not good for settle Refund (before/during usage) Refund not good for settle No usage transactions available Refund without sale transactions Replacement Table 2: Requirements

7 Samples For further clarification this section lists some sample scenarios. The numbers in these samples are fictive, but the calculation method is real.

7.1 Timelines The following timeline applies to monthly products:

 T1: the product instance is sold  T2: the validity of the product instance starts and it cannot be refunded anymore  T3: the validity of the product instance ends  T3 + 8: the first opportunity to settle the product sale amount (if amount is known)  T1 + 62: the last opportunity to settle the product sale amount (if amount is known)  T1 + 63: the inability to settle the product sale amount is reported (if amount is unknown)

100e6ee15de29be132b522334be3c74d7a.docx HLD Product Settlement Phase 2 The following timeline applies to yearly products:

 T1: the product instance is sold  T2: the validity of the product instance starts  T1 + 62: the last day on which the product sale transaction is processed by CCHS  T1 + 63: the inability to settle the product sale amount is reported (if amount is unknown)  T3: the first quarter year of validity of the product instance ends and is settled (if amount is known)  T4: the second quarter year of validity of the product instance ends and is settled (if amount is known)  T5: the third quarter year of validity of the product instance ends and is settled (if amount is known)  T6: the fourth quarter year of validity of the product instance ends  T6 + 8: the fourth quarter of the product sale amount is settled (if amount is known)

7.2 Sample A Product characteristics:  Product: Altijd Korting Maand (monthly)  Product Amount: € 16,50 A

Product instance 1 characteristics:  Product sale date: August 1st 2011  Product effect date: August 8th 2011  Product expiry date: September 7th 2011

Product instance 2 characteristics:  Product sale date: August 1st 2011  Product effect date: August 8th 2011  Product expiry date: September 7th 2011

7.2.1 Apportionment Key Calculation Product instance 1 apportionment keys based on product instance 1 usage as calculated September 15 th 2011:  CXX: o Concession 1: € 56,42 % B o Concession 4: 125,68 37,49 % C € 83,50  GVB : o Concession 2: € 1,23 0,55 % D  HTM: o Concession 3: € 12,34 5,54 % E Total € 100,00 % 222,75

Product instance 2 apportionment keys based on product instance 2 usage as calculated September 15 th 2011:  CXX: o Concession 1: € 83,50 31,24 % F o Concession 4: € 12,34 4,62 % G  GVB : o Concession 2: € 47,02 % H 125,68  HTM: o Concession 3: 45,76 17,12 % I Total € 100,00 % 267,28

7.2.2 Product Settlement Product instance 1 and 2 settlement based on calculated apportionment keys on September 15 th 2011:  CXX: . (A x (B + C)) + (A x (F+G)) . € 16,50 x 93,91 % + € 16,50 x 35,86 % = € 15,50 + € 5,92 = € 21,42  GVB: . A x D + (A x H) . € 16,50 x 0,55 % + € 16,50 x 47,02 % = € 0,09 + € 7,76 = € 7,85  HTM: . A x E + (A x I) . € 16,50 x 5,54 % + € 16,50 x 17,12 % = € 0,91 + € 2,82 = € 3,73

7.3 Sample B Product characteristics:  Product: Altijd Korting Jaar (yearly)  Product Amount: € 165,00 A

Product instance 3 characteristics:  Product sale date: August 1st 2011  Product effect date: August 10th 2011  Product expiry date: August 9th 2012

7.3.1 Apportionment Key Calculation Product instance 3 apportionment keys based on product instance 3 usage as calculated for the first quarter year of the product instance validity November 9 th 2011:  CXX: o Concession 1: € 1300,08 48,98 % B o Concession 4: € 765,43 28,84 % C  HTM: o Concession 2: € 45,67 1,72 % D  RET: o Concession 3: € 543,21 20,46 % E Total € 2654,39 100,00 %

7.3.2 Product Settlement Product instance 3 settlement for the first quarter year of the product instance validity based on calculated apportionment keys on November 9 th 2011:  CXX: . A x 25 % x (B + C) . € 165,00 x 25 % x 77,82 % = € 32,10  HTM: . A x 25 % x D . € 165,00 x 25 % x 1,72 % = € 0,71  RET: . A x 25 % x E . € 165,00 x 25 % x 20,46 % = € 8,44

Note: the settlement of the second and third quarter takes place immediately upon quarter expiration. The settlement of the fourth (and last quarter) takes place 8 days after the product instance expires to allow for late transactions. Each of these three settlements take place based on the apportionment keys calculated for their respective quarters.

8 Phasing It is envisaged there will be 4 phases: 1. Phase 1, in which discount products are settled based on assumed settlement rules. This phase is also referred to as the PoC and is already completed. It forms the basis for the 2. Interim Phase, in which the “Altijd Korting” product has been deployed in the production environment and is settled in a pragmatic way using mainly the phase 1 solution. 3. Phase 2 to settle the “Altijd Korting” product in accordance with the associated LPR settlement rules. The Phase 2 solution supersedes the Phase 1 solution. 4. Phase 3 is mentioned for completeness sake as it is beyond the scope of this document. The purpose of Phase 3 is to settle all interoperable products based on the rules to be defined by the LPR.

3. Impact on the Business Architecture

9 Impact on the Business Model There is no impact on the Business Model. The business roles involved in Product Settlement are:  Nationwide product owner (LPR)  Product retailers (PR)  Service providers (SP)  Clearing operator (CO)

Phase 2 is in fact an implementation of rules that were already defined in the HRP.

10 Impact on the Business Processes (Use Cases) Although the LPR as product owner is an existing role within the HRP, this role has never been implemented. Some minor changes are to be expected in the business processes, such as:  Reporting to the LPR concerning: o Proposed apportion keys; o Turnover of products; this information is used by the LPR to determine whether fixed or variable apportionment keys are to be used for that product.  Feedback from the LPR to TLS concerning apportionment keys to be used.  Communication with the LPR regarding claims of participants concerning product settlement.

A minor change is to be expected for the PR. The PR has to give the CO access to an account and assure the credit is enough for the CO to debit the product sales. It is up to the PR to monitor that the debits match the product sales.

For the SP there is no significant change. CO will perform settlement to the account number as specified by the SP.

Within the CO no new business processes are to be expected; changes can be considered as an enhancement on the current business processes.

11 Implementation business processes As the LPR is still in the starting-up phase it is to be expected that a grow model will be used to implement the business processes.

It is envisaged there will be 4 phases: 1. Phase 1, in which discount products are settled based on assumed settlement rules. This phase is also referred to as the PoC and is already completed. It forms the basis for the 2. Interim Phase, in which the “Altijd Korting” product has been deployed in the production environment and is settled in a pragmatic way using mainly the phase 1 solution. 3. Phase 2 to settle the “Altijd Korting” product in accordance with the associated LPR settlement rules. The Phase 2 solution supersedes the Phase 1 solution. 4. Phase 3 is mentioned for completeness sake as it is beyond the scope of this document. The purpose of Phase 3 is to settle all interoperable products based on the rules to be defined by the LPR.

4. Impact on the Information Architecture This chapter describes the impact on the information architecture as compared with the phase 1 solution.

12 Impact on the Application Architecture The phase 2 solution has no impact on the application architecture compared to the phase 1 solution6. Neither new systems nor new system components are introduced. The current post- calculation functionality will be enhanced. For completeness sake the figure below depicts the application architecture involved (in red) in this functionality enhancement.

6 This impact applies to the business functionality. However, there may be impact on the technology. In phase 1 data was aggregated on a PTO level, in phase 2 data is aggregated on a per card per concession level. This fine granularity may have an impact on the technology used, but this is outside the scope of the HLD.

180e6ee15de29be132b522334be3c74d7a.docx HLD Product Settlement Phase 2 13 Impact on the Data Architecture In phase 2 there is no impact on the data architecture from a business point of view. The enhanced product settlement functionality will most likely require changes to the CCHS database (new tables, fields etc.), but these changes are too detailed for this high level design.

14 Impact on Data Security In phase 2 there is no major impact on the data security. However, the fact that we will be accumulating data per card is a source of potential data exposure. We need to make sure that usage information and card information are somehow dissociated to avoid privacy exposure risks.

15 Implementation Architecture It is envisaged there will be 4 phases: 1. Phase 1, in which discount products are settled based on assumed settlement rules. This phase is also referred to as the PoC and is already completed. It forms the basis for the 2. Interim Phase, in which the “Altijd Korting” product has been deployed in the production environment and is settled in a pragmatic way using mainly the phase 1 solution. 3. Phase 2 to settle the “Altijd Korting” product in accordance with the associated LPR settlement rules. The Phase 2 solution supersedes the Phase 1 solution. 4. Phase 3 is mentioned for completeness sake as it is beyond the scope of this document. The purpose of Phase 3 is to settle all interoperable products based on the rules to be defined by the LPR.

5. Impact on the Scheme

16 Impact on the HRP, Registrar In phase 2 there is neither impact on the HRP nor on the Registrar.

17 Impact on SDOA/DIS In phase 2 there is no impact on the SDOA/DIS.

200e6ee15de29be132b522334be3c74d7a.docx