1. UNCLASSIFIED SuperStream Working Group Data Standards Reportback Philip Hind National Program Manager Data Standards & E-Commerce 28 February 2011

2. UNCLASSIFIED 2 Contents Vision & Success Measures Rollover Process & Data Elements Contribution Process & Data Elements Enabling Services

3. UNCLASSIFIED 3 Design principles The vision of SuperStream Measures of success Principle 1 – Always choose the end-to-end pathway that increases the long- term efficiency of the superannuation system Principle 2 – Design for reuse Principle 3 – Deliver a quality solution which drives the right behavioural change in an agreed timeframe Principle 4 – Actions should occur as early in the workflow as possible Principle 5 – Align with relevant established international and Australian standards Principle 6 – Define business data used in SuperStream within the SBR XBRL taxonomy, exploiting the capability for extensions and continued refinement and development over time Principle 7 – Design the solution so that it does not prescribe the internal solutions for stakeholders Principle 8 – Design the solution having regard to, but not limited by, the development and transition costs for stakeholders Principle 9 – Build partnerships among stakeholders Engaging stakeholders online with high integrity, fast response and better value for members. Collaborating on common processes, competing on difference. “ “ Measure 1 – Improved stakeholder experience > for members and employers Measure 2 – Lower cost of processing > for contributions, rollovers and reporting Measure 3 – Straight through processing of common transactions > for contributions and roll-overs > at an agreed industry standard Measure 4 – Conformance with the Superstream e-commerce standard > for employers, funds and their agents Note: all metrics are indicative only and are the subject of a joint ATO/industry task group reporting back to the Superstream Working Group on 1 April.

4. UNCLASSIFIED 4 Contributions SuperStream: Transactions in scope DRAFT v1.4 29/03/11  New Member Registration  Member Choice of Fund  Employer Registration  Employer Maintenance  Member Maintenance  Member Contributions**  Receipt of message  Errors/exceptions***  Payments  Ceased Payment Notice Roll-overs & Transfers Reporting to Government  TFN Declaration  Member cont. statement  Lost Members report  Unclaimed Monies statement  SG Charge statement  SG Late Payment Offset  Excess Contributions Tax  Payment Variation  Matching request  AUSTRAC – AML  Member Account Balances* * With some G2B and C2B capability **Needs to include possible variations in contributions by employee, employer and govt *** Including funds returned to source  Transfers  Rollovers  Receipt of message  Errors/exceptions  Payments Enabling Services  TFN Validation  ABN Validation  Fund Bank Account/ Member Account Validation  Super Fund identifiers and contacts (incl SPIN)  Employer identifiers and contacts Design Issues  Definition?  Importance?  Who delivers?  When delivered?  Cost of service?  Integration to SBR? ? B2G* B2B* * A G2C channel in the form of an Individuals Portal * Complemented by a B2C channel Employer to fund Employer to government Fund to employer Fund to fund Fund to government Government to fund Government to citizen

5. UNCLASSIFIED 5 Data view – Rollovers There is a high degree of alignment between industry and ATO on the data and terms required for this process. SBR currently has about 80% of these terms defined and could quickly close the gap on the remainder. Rollover  Fund role (source/target)  ABN  Entity name  Postal address  Contact name*  Preferred contact method*  Primary contact fllag*  Phone number*  Fax Nubmer  Other contact methods  SPIN? Fund entity details  TFN*  TFN Status*  Person’s name  Postal address  DOB  Sex  Phone number*  Email address*  Member account no. Member details  Payment Type  Service period start date  Rollover components  Preservation amounts  Contributed amounts  Rollover calculation date Account details  Contact name  Phone number  Email address  Signature  Authorising Date Authorisation Preservation amounts  Preserved amount  Restricted non-preserved  Unrestricted non-preserved Contributed amounts  FY ending  Employer contributed  Personal contributed  CGT cap election – small business retirement exemption  CGT cap election – small business 15-yr exemption  Personal injury  Spouse & child contributions  Other family & friends  Directed termination payments (taxable)  Assessable foreign fund  Non-assessable foreign fund  Transferred from reserves – assessable  Transferred from reserves – non-assessable  All current yr contributions Issues: Explore data differences with swimEC, eg:  Is ‘Rollover Type’ in swinEC the same as ‘Payment Type’?  ‘Person’s name’ is split into Given and Family name  ‘Street’ has an optional ‘Line 2’  ‘DPID’ is an additional field  ‘Phone number’ is split into home and daytime contact numbers Defined in standard ATO form only (NAT 70944-05.2007) Defined in ATO form and in SBR taxonomy Defined in swimEC message guidelines (v8.3) Optional field in swimEC Postal address  Street  Suburb  State*  Postcode*  Country*  DPID* Rollover component  Tax-free component  Element taxed in the fund  Element untaxed in the fund  Supplier relationship  ABN (or ID)  Entity name  Postal address  Contact name  Phone number  Fax Supplier details Note: Does not include message header details  (Source) Target Product ID  (Source) Target BSB  (Source) Target Account No  Target Account Name  Sender Transaction Ref No.  Sender Transaction Creation date  Target Fund Administrator Name  Payer Name  Super Member Rollover Payment details ‘Supplier’ also referred to as ‘agent’ or ‘sender’

6. UNCLASSIFIED 6 Rollover Process (‘to be’ view) Business Interaction Perspective

7. UNCLASSIFIED 7 Rollover Interaction Summary InteractionDescription 1.Rollover Request A rollover request* is always initiated by the member. In the ‘to be’ view, the request could be in either electronic or paper form. A Fund could potentially receive an electronic rollover request from one of several parties on behalf of the member, including approved agents, government and the target fund. It is proposed that this interaction invokes validation requests to confirm party details and check TFN integrity. This service may be provided in whole or part by the ATO, or by alternative service providers. 2 Rollover Transaction The rollover transaction* contains details of the rollover benefit which are sent by the Source Fund to the Target Fund. The data includes a unique transaction identifier which enables reconciliation with the matching payment transaction. 3 Rollover Payment The rollover payment *contains payment values and reference details of the benefits paid by the Source Fund to the Target Fund. Existing industry standard payment mechanisms would be used and include a unique transaction identifier which enables reconciliation with the matching rollover data transaction. 4. Rollover Acknowledgement The acknowledgement contains a message from the Target Fund to the Source Fund confirming that the Rollover transaction has been completed successfully. 5. Member Notification Under the Corporations Act both the Source and the Target Fund is to provide a notice to the member to acknowledge the rollover transaction. This interaction is assumed to be outside the scope of the SuperStream solution and would need to rely on existing channels between Funds and their members (although the SuperStream standards could be leveraged to provide an online experience in the future). Enabling ServiceDescription 6. Registry An authoritative register which is maintained as the source of truth for all repeatable information relating to parties, identifiers and defined attributes. In reality, this may involve more than one registry service referenced by separate calls to each service. * Each interaction would contain details as defined by the SuperStream data standard (incorporating any existing standards as needed).

8. UNCLASSIFIED 8 Interaction1.Design FactsDesign Questions 1.Rollover Request.1.Currently rollovers can only be triggered by the member via the use of paper forms. 2.Future desing enables request to be triggered electronically from the member or an authorised agent 3.Assume industry standard adopted for authentication and authorisation. 4.Triggering Partial Rollover transactions is out of scope while whole rollovers are in. 1.Is there a need for an industry standard that all request go to the Source Fund and not the Target Fund? 2.What enabling services are required to drive data integrity and when invoked? TFN Validation? Fund Validation? Other? 2 Rollover Transaction1. Message design will need to cater for both single and bulk rollover transactions. 1.Opportunity for potential data rationalisaiton: RBS requirement could be significantly reduced if legislation changes enabled funds to supply only minimum data needed for the rollover transaction and the more detailed benefit data is supplied via the MCS. 3 Rollover Payment1.Two separate message streams for the information and payment are required at present – along with a reconciliation identifier. 2.Ability to place the information and payment within a single message is likely to be 5-plus years away (future evolution of ISO200022) 1.Can SwimEC payment solution be leveraged to enable matching of the rollover information flow to the payment? Other variants? 4. Rollover Acknowledgement 1.Currently there is no acknowledgment issued between funds – it is a fire and forget implementation. If an problem is encountered then the issue is manually rectified. 1.Should every transaction return a success receipt; alternatively, should a reply only be provided when there is an issue encountered? 2.If a reply is always provided what standard processes are needed? 3.Where a failure reply message occurs, what should be the standard process (re-send?) 5. Member Notification1.Both the Source and Target Fund are required to supply the member with information pertaining to the rollover transaction. 2.This will need to be actioned using existing channels established between the fund and the member. NONE Rollover Interactions Design Facts & Questions

9. UNCLASSIFIED 9 What is an enabling service for SuperStream E-commerce? SuperStream: Enabling Services Draft for discussion only Potential Enabling Services TFN Validation A service that allows an entity to verify the integrity of information before they send it or when they receive it. Service nameWhat does the service do?Who uses?When used? ABN Validation Product/ Member Account Validation Bank Account verification Employer contacts Does the TFN, Name and DOB supplied constitute a valid identity? Does the ABN and Business Name constitute a valid identity? Is the Product or Member Account number valid for the super fund? Is the bank account valid for the receiving fund? Or if SMSF, for trustee? Confirm the contact details for the fund. Confirm the contact details for the employer. Fund contacts Employer, Fund, ATO Fund, ATO Employer, Fund, ATO All major transactions Member registration, Contributions All major transactions Member registration, Rollovers Member registration (SMSF), Rollovers Data Owner Prevent transaction failure Efficiency ATO ABR Fund Fund / Employer Fund Employer

10. UNCLASSIFIED 10 SuperStream: Enabling Services (cont) Draft for discussion only Straw man for Enabling Services TFN Validation Service nameWho providesHow available?What new things are needed? ABN Validation Product/ Member Account Validation Bank Account verification Employer contacts ATO ABR Funds or ABR Funds, banks or ABR Fund contacts SBR Web Service, Online TFN Declaration, bulk? SBR Web Service, Online at ABR site SBR Web Service, ???? Web Service Expose similar existing ATO service externally Expose similar existing service via SBR Register of products by Fund, register of accounts by fund or account number algorithm by fund. Funds or ABR Employers or ABR Web Service Register of every bank account or an orchestrated method of validating with fund. If ABR, frequent update by funds. If ABR, frequent update by employers.

11. UNCLASSIFIED 11  What contribution do we expect each service to make to improving data quality?  How do we strike the right balance between data quality and continuity of a business process?  What is the right intervention point ( ‘ as early in the process as possible ’ )?  Is the service real-time? Or would some parts be cached locally with a 24-hr refresh?  What happens when a validation service is unavailable?  What do we populate to the transaction from the register? What do we check? What do we correct?  What happens when a validation fails?  What migration path will partners follow in replacing legacy registry services?  What changes in process and behaviour are required to ensure the master register(s) is as accurate and up-to-date as possible? Design Issues - Summary 1.Definition? Data fields? 2.Importance? 3.Who delivers? Supports? 4.When delivered? 5.Cost/benefit of service? 6.Integration to SBR? 7.Data maintenance? Specific Design Questions Ultimately, there are a series of design issues which need to be worked through in a systematic manner. To advance our preliminary work, some specific design questions require early clarification of either requirements or approach: SuperStream: Enabling Services (cont)