Electronic Portability FormMessage Implementation Guide

specification / software producers / 17/06/2013 / Unclassified
format / Audience / Date / Classification
Electronic Portability Form
Message Implementation Guide
Date: 30 June 2013
Production Release – suitable for use
This document and its attachments are Unclassified / For further information or questions, contact the SBR Service Desk at or call 1300 488 231.

VERSION CONTROL

Version / Release date / Description of changes
1.0 / 30/06/2013 / Draft for consultation – external industry consultation
1.0 / 17/06/2013 / Production release – suitable for use
The changes from version 0.1 are:
1. The inclusion of an RSA provider as an authorised entity who will receive EPF forms has been updated in this MIG.
2. Section 4.1: The message sender context, entity identifier instruction / rule has been updated to state that this identifier will always be set to the ATO’s ABN (updateincorporated as a result of ASP feedback).
3. Section 5.4.1 The ‘AddressDetails.Usage.Code’ in the member rollover transaction data context table has been updated from “POS” to “RES”.
4. The typed dimension containers updated to typed elements for each context specification, the message sender context instruction has been updated and there has been an additional message sender context added to the sample XBRL instance for the EPF message.
5. The SuperannuationFundDetails.MemberClient.Identifier (Seq no 8) in the Member Rollover Transaction Details – data content table has been updated from ‘optional’ to ‘Mandatory’.
ENDORSEMENT
APPROVAL
Chief Solutions Architect
Standard Business Reporting
MichaelFerris / Project Manager
Strategic Web Services
Australian Taxation Office

Copyright

© Commonwealth of Australia 2013 (see exceptions below).
This work is copyright. Use of this Information and Material is subject to the terms and conditions in the "SBR Disclaimer and Conditions of Use" which is available at . You must ensure that you comply with those terms and conditions. In particular, those terms and conditions include disclaimers and limitations on the liability of the Commonwealth and an indemnity from you to the Commonwealth and its personnel, the SBR Agencies and their personnel.
You must include this copyright notice in all copies of this Information and Material which you create. If you modify, adapt or prepare derivative works of the Information and Material, the notice must still be included but you must add your own copyright statement to your modification, adaptation or derivative work which makes clear the nature of your modification, adaptation or derivative work and you must include an acknowledgement that the adaptation, modification or derivative work is based on Commonwealthor SBR Agency owned Information and Material. Copyright in SBR Agency specific aspects of the SBR Reporting Taxonomy is owned by the relevant SBR Agency.

Version1.0UnclassifiedPAGE1 OF 30

Electronic Portability FormMessage Implementation Guide

Table of contents

1Introduction

1.1Purpose

1.2Audience and Scope

1.3References

1.4Change Management

2 Business Overview

3Message Overview

3.1EPF Message Location

3.2Standard Business Document Message (SBDM)

3.3Reporting Taxonomy

3.4ERROR HANDLING

4XBRL Context Specifications

4.1Context specification – message sender

4.2Context specification – message receiver

4.3Context specification – member rollover transaction

4.4TFN usage within context

4.5Unique superannuation identifiers within context

5Initiate rollover request message specification

5.1XBRL context specifications

5.2Message content tables

5.2.1Message sender details

5.3Message receiver details

5.3.1Initiate Rollover Request – Message Receiver Data Content Table

5.4Member rollover transaction details

5.4.1Initiate Rollover Request – Member Data Content Table

Appendix A – The Message Content Table Explained

Appendix B – Additional Business Rules

Appendix C – Logical Message Structure

Appendix D – SBDH Request Elements

APPENDIX E – XBRL INSTANCE DOCUMENTS

Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 . The use of the word “Mandatory” is to be read as “MUST”.

1Introduction

1.1Purpose

The purpose of this Message Implementation Guide (MIG) is to assist software developers, in the implementation of the Australian Taxation Office’s (ATO’s) outbound Electronic Portability Form (EPF).
The EPF is an outbound message sent by the ATO to a superannuation fund, a retirement savings account (RSA) provider or an intermediary acting on behalf of a fund or a RSA provider, to notify the entity of a member’s election to rollover their whole superannuation benefit balance to another superannuation fund or RSA provider.

For the purposes of this document, a reference to a superannuation fund also is a reference to a RSA provider.

The implementation of the ATO’s EPF will simplify whole account balance rollovers for both members and superannuation fundsand will ensure that superannuation rollovers comply with the new Superannuation Data and Payment Standard. Further information relating to this standard can be located at the References section (1.3) of this MIG.

1.2Audience and Scope

This document contains the message specificationsand supporting documentation required to allow forthe consumption of the ATO’s outboundEPF message.

All supporting documentation for this MIG is outlined in the references section (1.3). It is assumed that the consumer of this MIG is familiar with this documentation prior to the implementation of the EPF.

1.3References

Ref / Document Link / Document description
1) / The Superannuation Data and Payment Standard and associated Schedules at
/ Reference document detailing the Superannuation Data and Payment Standard which includes the various messages/interactions.
2) / The Superannuation Data and Payment Standard XBRL Reporting Taxonomies can be accessed and downloadedvia the YETI Taxonomy Viewer at
/ The EPF Message uses the Initiate Rollover Request message which is part of the Superannuation Data and Payment Standard XBRL Taxonomy.
3) / The SBR Taxonomy Architecture document can be downloaded at
/ Reference document that describes the structure of the SBR taxonomy, its naming conventions, release management and change control, and how each business interaction fits within the architecture.

1.4Change Management

If a material change is required to thisMIG,the document will be re-released

2 BusinessOverview

Explanatory notes:
Superannuation fund member / The individual for whose benefit the money is being held and rolled over.
RSA holder / An individual who holds a retirement savings account (RSA) with an RSA provider and who makes contributions, or on whose behalf contributions are made to the RSA.
Superannuation fund / With respect to rollovers the two superannuation funds are referred to in this document as:
Transferring superannuation fund – the superannuation fund that originally holds the member’s interest and is paying an amount from that interest to another superannuation fund
Receiving superannuation fund – the superannuation fund that is to receive the payment from the transferring superannuation fund and allocate the amount to the member’s interest in the receiving superannuation fund.
RSA provider / A financial institution that offers RSAs. For the purpose of EPF, an RSA provider may also be a transferring fund i.e. the entity the EPF form will be transmitted to.

The ATO Outbound EPF will provide complying superannuation funds and RSA providers with a message notifying the entity that a member has elected to transfer their whole superannuation account balance from one superannuation fundto another. A membermay also elect to have their whole balance transferred to their own Self Managed Super Fund (SMSF).

It is the responsibility of the transferring entity to rollover the member’s whole balance to the receiving entity.
For EPF, the transferring superannuation fundis the fundwho will receive the outbound message from the ATO.

Rollover business interaction

Figure 1 illustrates the business stakeholders and the message exchanges required to perform the member rollover business interaction. This is a holistic view which combines many possible rollover business scenarios.

Figure 2 illustrates the business stakeholders and the message exchanges required to perform the initiate rollover request only. The Initiate Rollover Request interaction utilises the EPF.

Figure 1 - Rollover Business Interaction

Figure 2 – Electronic Portability Form Interaction

3Message Overview

3.1EPF Message Location

Superannuation fundswill be able to download EPF messages from the ATO Business Portal.

3.2Standard Business Document Message (SBDM)

The EPF XBRL messagewill be containedwithin an SBDM envelope. For the element details and values used in the Standard Business Document Header (SBDH) component of the SBDM,please see Appendix D.

3.3Reporting Taxonomy

The report version for EPF is sprrol.0001.initiaterollover.request.02.00. For further information regarding this report version,please seethe Reference section (1.3) of this document.
To view message specifications for each rollover interaction, using the sprrol.0001.initiaterollover.request.02.00, please refer to the Data Payment and Standards Rollover MIG. This MIG can also be accessed by following the link to the Data Payment and Standards in the References section (1.3) of this document.

3.4ERROR HANDLING

If a superannuation fundexperiences errors with the message content returned in the XBRL message for EPF, the fundis required to contact the transferring member direct. Where a superannuation fundexperiences issues with regards to the downloading and subsequent consumption of an XBRL message for EPF, the superannuation fundshould contact the ATO direct on for assistance with the resolution.

.

Version1.0UnclassifiedPAGE1 OF 30

Electronic Portability FormMessage Implementation Guide

4XBRL Context Specifications

The following sections define the context specifications that will be used within this MIG. The context types are allocated to the individual data elements within the message specifications below.

4.1Context specification – message sender

(a) The message sender is the organisational entity that sends the specific rollover message. For EPF, the message sender will always be the Australian Taxation Office.

(b) The message sender context SHALL conform with the specifications in the Message Sender Context Specification Table.

Message Sender Context Specification Table

Context Data Concept / Requirement / Instructions/Rules
Context Identifier / Mandatory / This is a unique identifier used to link the data element to a defined XBRL context.
Entity Identifier / Mandatory / This field will always be set to the ATO’s ABN.
Entity Identifier Scheme / Mandatory / This field SHALLbe set to
Entity Segment / Mandatory / Explicit member dimension ReportPartyType (“ReportPartyTypeDimension”) must be set to “MessageSender”.
Period Date - Start Date / Mandatory / 1. This is a mandatory item within the XBRL specification so it must be populated with a date.The date will be set to the date the superannuation fund has requested the message, thus the date will always be set to the current date.
Period Date - End Date

4.2Context specification – message receiver

(a) The message receiver is the organisational entity that receives the specific rollover message for processing.

(b) The message receiver context MUST conform with the specifications in the Message Receiver Context Specification Table.

Message Receiver Context Specification Table

Context Data Concept / Requirement / Instructions/Rules
Context Identifier / Mandatory / This is a unique identifier used to link the data element to a defined XBRL context.
Entity Identifier / Mandatory / This field shall be set to the ABN of the party that will receive this document.
Entity Identifier Scheme / Mandatory / This field must be set to
Entity Segment / Mandatory / Explicit member dimension ReportPartyType (“ReportPartyTypeDimension”) must be set to “MessageReceiver”.
Period Date - Start Date / Mandatory / 1. This is a mandatory item within the XBRL specification so it must be populated with a date and this MIG suggests setting both start and end date to the current date. The actual value will not be tested only whether it is present.
Period Date - End Date

Version 1.0UnclassifiedPAGE1 OF 30

Electronic Portability FormMessage Implementation Guide

4.3Context specification – member rollover transaction

(a) This context is used to identify data elements relating to a member rollover transaction.

(b) The member rollover transaction context MUST conform with the specifications in the Member Rollover Transaction Context Specification Table.

Member Rollover Transaction Context Specification Table

Context Data Concept / Requirement / Instructions/Rules
Context Identifier / Mandatory / This is a unique identifier used to link the data element to a defined XBRL context.
Entity Identifier / Mandatory / If the Superannuation Fund Member Tax File Number (TFN)is known then the TFN MUST be populated into the Entity Identifier and SHOULD be a valid TFN registered with the ATO. See section 04.4 for details on using the TFN as the Entity Identifier.
1. If the Member has chosen not to disclose their TFN to the Transferring or Receiving fund then the Entity Identifier MUST be set to an identifier which will uniquely identify the Superannuation Fund Member within the instance document. This identifier is to be a unique value determined by the party producing the message.
2. The identifier MUST uniquely identify the Superannuation Fund Member within the instance document. It maybe possible for the same identifier to appear in multiple context declarations (i.e. multiple context cardinality). This test is to determine that the same identifier is not being used for different individuals within the instance document. To determine this, when an instance document contains multiple instances of the same identifier, the demographic details should be compared to ensure they are referencing the same individual.
Entity Identifier Scheme / Mandatory / 1. If the Entity Identifier is a TFN then this field SHALL be set to
2. If the Entity Identifier is a unique identifier provided by the party producing the message then this field SHALL be set to
NOTE: this value will determine the type of identifier used within the Entity Identifier hence it is critical that the correct EntityIdentifier Scheme is provided. If the scheme is set to , this will indicate that the superannuation fund member has not provided their TFN or the entity responsible for the message does not know their TFN.
If the scheme is set to by mistake and the TFN was supplied then the TFN SHOULD be treated as not being supplied.
Entity Segment / Mandatory / Explicit member dimension ReportPartyType (“ReportPartyTypeDimension”) must be set to “SuperFundMember”.
Mandatory / Typed Dimension = “TransferringSuperFundAllocatedMemberIDDimension” with a simple container = “SuperannuationFundDetails.MemberClient.Identifier” set to the Member ID allocated by the TransferringFund to the member within the rollover.
1. Member ID must be known to the Transferring Fund.
Mandatory / Typed Dimension = “TransferringSuperFundABNDimension” with a simple container = “Identifiers.AustralianBusinessNumber.Identifier” set to the ABN of the superannuation fund who is the Transferor of the rollover.
Optional / Typed Dimension = “TransferringSuperannuationFundUniqueSuperannuationtIdentifierDimension” with simple container = “SuperannuationFundDetails.UniqueSuperannuationIdentifier.Identifier” must be set to the unique superannuation identifier of the superannuation product from which the rollover has been sourced, specified in this MIG (refer to Section 04.5).
This dimension MAY be provided if the Transferring Fund has one or more unique superannuation identifiers.
Note - If the Fund does not have unique superannuation identifiers,then this dimension MUST NOT be provided within the context declaration.
1. Must be a valid unique superannuation identifier within the Transferring Fund.
Mandatory / Typed Dimension = “ReceivingSuperFundABNDimension” with a simple container = “Identifiers.AustralianBusinessNumber.Identifier” set to the ABN of the superannuation fund who is the Receiver of the rollover.
Optional / Typed Dimension = “ReceivingSuperannuationFundUniqueSuperannuationIdentifierDimension” with simple container = “SuperannuationFundDetails.UniqueSuperannuationIdentifier.Identifier” must be set to the unique superannuation identifier allocated to the Receiving Superannuation Product specified in this MIG (refer to Section 04.5).
This dimension MAY be provided if the Receiving Fund has one or more unique superannuation identifiers.
Note - If the Fund does not have unique superannuation identifiers, then this dimension MUST NOT be provided within the context declaration.
1.Must be a valid unique superannuation identifier within the Receiving Fund.
Period Date - Start Date / Mandatory / 1. This is a mandatory item within the XBRL specification so it must be populated with a date and this MIG suggests setting both start and end date to the current date. The actual value will not be tested only whether it is present.
Period Date - End Date

Version 1.0UnclassifiedPAGE1 OF 30

Electronic Portability FormMessage Implementation Guide

4.4TFN usage within context

(a) If a superannuation fund member has elected not to supply their TFN, the data element, Identifiers.TaxFileNumberNotProvided.Indicator or the TFN cannot be validated.The Identifiers.TaxFileNumberNotProvided.IndicatorMUST be set to TRUE which formally informs the superannuation fund that the superannuation fund member has chosen not to supply their TFN.

(b) If the superannuation fund member has supplied their TFN then the data element, Identifiers.TaxFileNumberNotProvided.Indicator, MUST be set to FALSE.

4.5Unique superannuation identifiers within context

(a) If there is an obligation imposed on an entity to use a unique superannuation identifier, one of the following two conventions MUST be followed to generate the unique superannuation identifier:

  1. the entity’s ABN followed by three (3) numerals
  2. another kind of unique identifier approved in writing by the Commissioner of Taxation.

(b) A superannuation fund may use either method to identify their individual products.

Version 1.0UnclassifiedPAGE1 OF 30

Electronic Portability FormMessage Implementation Guide

5Initiate rollover request message specification

Explanatory notes:
  • The following sections describe the contextualisation and the data elements required to be supplied within the XBRL instance document.

5.1XBRL context specifications

(a)The contextualisation required for the Initiate Rollover Request message MUST conform with the specifications in the Initiate Rollover Request Context Table.

(b)The Context Specification section (see section 4 of this document) contains the development requirements of each context identified within the Context Specification column.

Initiate Rollover Request Context Table

Context spec / Instructions / Rules
Message Sender
/
1. Mandatory and MUST only be one context declaration.
Message Receiver
/
1. Mandatory and MUST only be one context declaration.
Member Rollover Transaction
/
1. Mandatory and MUST have at least 1 context declaration but MAY have many.

Version 1.0UnclassifiedPAGE1 OF 30