Account-Based Transaction Processing Risk Mitigation Methods

Transcription

1 -Based Transaction Processing Risk Mitigation Methods 2014 APTA Revenue Management Summit CH2M HILL, Inc. Pete Comps Chicago Doug Deckert Baltimore

2 A Little History Not that long ago, fare collection was all about securing cash and tokens If you lost the data, you still had the revenue in the farebox When card-based fare systems emerged, the data on the card represented the revenue (e.g., stored value or floating period passes) If you lost the back-end data, the data on the card remained intact, and the revenue was still in the bank Now, with account-based systems, bank card payments, mobile ticketing, etc., the data IS the revenue Lose the data, and you lose the revenue There is a variety of data sources, types, and storage locations Thus, there are many ways to lose revenue

3 -Based Fare Systems Benefits compared to card-based systems: Eliminates most proprietary designs on the card and at the card-to-reader interface Reduces security vulnerabilities from NFC smart phones ( cloning ) Supports third-party media and distribution networks Provides clear path to acceptance of EMV contactless bank cards

4 -Based Fare Systems Realities -based transaction processing depends on communications to back-end data system Data communications especially mobile are not 100% available Real-time communication and authorization affects transaction times, especially during peak periods Simpler device-to-card interface requires a highly complex back-end data system Back-end data system can be a single point of system failure Consistently satisfying desired transaction time no more than ½ second is challenging

5 Pure -Based Transaction Process When tapped, device reads card identity and conducts initial rules verifications (e.g., card expired, passback, etc.) 2. Device requests authorization from back-end data system 3. Back-end data system determines validity of account linked to card 4. Back-end data system informs device whether to allow entry 5. Back-end data system calculates transaction cost (according to business rules) and updates account Device Local Rules Check Go Stop Back-end Validity Check Price Transaction Note: transaction price determined after authorization to maintain desired transaction speed

6 Pure -Based Transaction Challenges Communication loss or capacity constraints Back-end data system failure or degraded operations Desired maximum transaction time of ½ second Device Local Rules Check Go Stop Back-end Validity Check Price Transaction Note: transaction price determined after authorization to maintain desired transaction speed

7 Risk Mitigation Strategies Always allow entry if no response from back-end within allotted time Risk of significant revenue loss Reduce risk of loss by adding validation processing at card readers Usually includes device-stored (distributed) risk mitigation lists Validation via search of stored lists can be in parallel with or instead of on-line authorization Requires robust process to maintain up-to-date lists on all devices

8 Transaction Processing Parallel with Risk Lists 1. When tapped, device reads card identity and conducts initial rules verifications (e.g., card expired, passback, etc.) 2. Device requests authorization from back-end data system AND Device commences search of risk mitigation lists 3. Back-end data system determines validity of account linked to card WHILE Device determines validity of account, based on risk list content 4. Back-end data system informs device whether to allow entry BUT If the back-end data system does not respond within the allotted time, the device uses the results of the risk list search to determine whether to allow entry 5. Back-end data system calculates transaction cost (according to business rules) and updates account and risk list content Back-end data system broadcasts risk list updates to all devices Device Local Rules Check Local Risk List Check Go Stop Local Risk List Back-end Validity Check Price Transaction Risk List

9 Transaction Processing Off-Line with Risk Lists When tapped, device reads card identity and conducts initial rules verifications (e.g., card expired, passback, etc.) 2. Device commences search of risk mitigation lists 3. Device determines validity of account, based on risk list content, and whether to allow entry 4. Device communicates transaction results to back-end data system 5. Back-end data system calculates transaction cost (according to business rules) and updates account and risk list content 6. Back-end data system broadcasts risk list updates to all devices Device Local Rules Check Local Risk List Check Go Stop Local Risk List Back-end Price Transaction Risk List

10 Risk List Content Parallel Positive and/or Negative lists Positive lists contain identifiers (tokens) of accounts with known validity Negative lists contain identifiers of accounts with insufficient value or lost/stolen cards Systems can include either or both list types List entries can also include other conditional information, such as pass types, low value warning, exception rules, etc. Parallel risk list processing need not have an entry for every account in use

11 Risk List Content Off-Line Off-line risk list should contain an entry for every account Each entry in the list must contain the account status Entries may also contain additional information, including: type (full / reduced fare) Pass type & expiration Low value warning

12 Risk List Content Additional account-specific information enables more post-transaction feedback, but can increase list content volatility and frequency of list updates Any entries for bank cards must be encrypted for PCI compliance

13 Risk List s Due to the size of the list files (up to 1 Gigabyte), updates are typically deltas only frequency should be configurable and governs the degree of risk mitigation If an account should be on the negative list, but is not, the user gets free rides (resulting in negative account balance) frequency also affects customer satisfaction If a user replenishes an account (taking it off the negative list), but the device list is not up to date, the user may be incorrectly denied entry If a new account should be on the positive list but is not, the user may be incorrectly denied entry Local Risk List Price Transaction Risk List

14 Risk List s Lists can be updated in batches every 3 to 5 minutes, or continuously updated (streamed) Lists on devices can be significantly out of date when: A device is shut down for several days A device is replaced with a spare device Specialized procedures may be necessary to ensure that such devices have current risk lists Periodic (e.g., daily) download of entire risk list to every device may improve overall list accuracy Means to monitor and report the currency of device risk lists recommended to gauge health of risk list update process Local Risk List Price Transaction Risk List

15 Helpful Fare Policies deposits can provide a cushion against negative account balances Capped fares can mitigate risk Enable customers to purchase unlimited ride passes (e.g., day passes) one ride at a time Limit potential per-account losses to the value of a day pass

16 Summary Data integrity can play a vital role in securing revenue for account-based systems Real-time authorization within ½ second can be difficult to achieve consistently Risk mitigation lists: Can offer backup to real-time authorization OR Equivalent authorization processing without real-time authorization challenges Require robust update processes Coordinated fare policies can further mitigate risks

17 A CH2M HILL Production Copyright MMXIV Co-Producer: Porky Pete Comps PETE (7383) Co-Producer: Daffy Doug Deckert