SuperStream Working Group Data Standards Reportback

1. SuperStream Working GroupData Standards Reportback Philip HindNational Program Manager Data Standards & E-Commerce 28 February 2011

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

3. The vision of SuperStream “ “ Engaging stakeholders online with high integrity, fast response and better value for members. Collaborating on common processes, competing on difference. Design principles 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 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. ? SuperStream: Transactions in scope Contributions Roll-overs & Transfers Reporting to Government B2B* B2G* B2B* • New Member Registration • Member Choice of Fund • Employer Registration • Employer Maintenance • Member Maintenance • Member Contributions** • Receipt of message • Errors/exceptions*** • Payments • Ceased Payment Notice • 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* • Transfers • Rollovers • Receipt of message • Errors/exceptions • Payments * Complemented by a B2C channel * With some G2B and C2B capability ** Needs to include possible variations in contributions by employee, employer and govt *** Including funds returned to source * A G2C channel in the form of an Individuals Portal Enabling Services • Design Issues • Definition? • Importance? • Who delivers? • When delivered? • Cost of service? • Integration to SBR? Employer to fund Employer to government Fund to employerFund to fund Fund to government Government to fund Government to citizen • Super Fund identifiers and contacts (incl SPIN) • Employer identifiers and contacts • TFN Validation • ABN Validation • Fund Bank Account/ Member Account Validation DRAFT v1.4 29/03/11

5. Rollover component • Tax-free component • Element taxed in the fund • Element untaxed in the fund Payment 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 • Preservation amounts • Preserved amount • Restricted non-preserved • Unrestricted non-preserved Supplier details • Supplier relationship • ABN (or ID) • Entity name • Postal address • Contact name • Phone number • Fax • 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 Data view – RolloversThere 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. Fund entity details • Postal address • Street • Suburb • State* • Postcode* • Country* • DPID* Member details • 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? • TFN* • TFN Status* • Person’s name • Postal address • DOB • Sex • Phone number* • Email address* • Member account no. ‘Supplier’ also referred to as ‘agent’ or ‘sender’ Rollover Account details Authorisation • Contact name • Phone number • Email address • Signature • Authorising Date • Payment Type • Service period start date • Rollover components • Preservation amounts • Contributed amounts • Rollover calculation date 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 • 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 Note: Does not include message header details

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

7. Rollover Interaction Summary * Each interaction would contain details as defined by the SuperStream data standard (incorporating any existing standards as needed).

8. Rollover Interactions Design Facts & Questions

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

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

11. SuperStream: Enabling Services (cont) 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: Design Issues - Summary Definition? Data fields? Importance? Who delivers? Supports? When delivered? Cost/benefit of service? Integration to SBR? Data maintenance? Specific Design Questions • 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?