Action Items Were Reviewed in Master Action Items List

Title: / SuperStream Technical Committee (SSTC)
Venue: / Australian Taxation Office – 6 Gladstone Street Moonee Ponds
(Teleconference |Phone: 1800 857 853 | Access Pin: 937 309#
Event Date: / 13 May 2015 / Start: / 10:00 / Finish: / 12:00
Chair: / Ty Winmill
contact / Matt Cheeseman / Contact Phone: / 02 62165648
Attendees:
Names/Section / Ty Winmill
Matt Cheeseman
Mark Napier
Graham Dawson
Scott Jeffery
Ian Colhoun
Ben Mangan
David Kerr
Yong Zhang
Grant Doherty
Ian Gibson
Gary Jacobs
John Kennedy
James Hancock
Matthew Rea
Brett Hillier
Nicholas Perrott / ATO
ATO
ATO
ATO
ATO
ATO
ATO
AAS
GBST
Westpac
Superchoice
BT Financial
CBA
Australian Payroll Association
Superpartners
Pillar Administration
Attache
Apologies:
Name/Section / John Shepherd
Andrew Blair
Mike Leditschke
Matt Guiliano
Caesar Baddah
Joseph O’Leary
Francis Cox
Ben Pearce
Frank Gilmartin
Joe Brasacchio
Stephen Russell
Sukesh Elati
next Meeting: / Teleconference only
Wednesday 27 May 2015 - 10:00am -11:00am
Agenda item: / 1
TOPIC: / Welcome and acceptance of minutes

The minutes from April 2015 were accepted.

Agenda item: / 2
TOPIC: / Action Items

Action items were reviewed in master action items list.

Grant raised an issue that has cropped up in testing in relation to response messaging. There are differing interpretations in relation to the progressive responses. This may need to be formalised into a paper.

·  Grant’s interpretation of a progressive response is that it allows funds to respond to any subset of the items within the original message over a number of responses. So if an MROR had 10 member registrations a fund could respond to the first one on one day and respond to the remaining nine the following day or not at all.

·  Gary mentioned the MIG says you can’t send a single message with progressive; it has to be at least two messages.

·  The other interpretation of what a progressive response is was that you could have dialogue between the fund and employer about a given item.

·  The issue is about the final outcome of the transaction. When you look at it in terms of what a warning is all the comments about the severity are at the maximum severity level not at the event item severity level. Some people have interpreted that a warning isn’t an outcome, it is just for information. This would mean these people are still waiting on an outcome.

·  We have discussed error codes in contributions in the past and ascertained that some error codes implied that you weren’t really sure on their status. You would actually be asking for more information or say action is pending. These error codes were removed at this time.

·  Some members agreed that any message sent, whether it be a warning or error, is the final message.

·  One option is that an error trumps anything else and supresses warnings. Another option is to state that warnings do not imply anything about the outcome of a transaction they simply give information.

·  The ATO are running a process to document how error messages are going to work when we do start using them. This will be part of the pilot in August that will involve participants in this group.

Agenda item: / 3
topic: / Oasis update

Mike Leditschke had nothing to report this month.

Agenda item: / 4
topic: / SBSCH issues update

Graham Dawson updated the group on SBSCH issues.

There have been five issues raised in relation to SBSCH. The issues are below.

·  A payment reconciliation error occurred because small amounts (less than $1) were rounded down in the message data but included exactly in the payment.

o  A solution for this has been designed and is scheduled for a June 13th 2015 release. Until the June 13th release, funds are being alerted when this issue is detected in an outgoing message to ensure that contributions are processed despite the reconciliation issue.

·  A message error was reported because the mandatory employer name field was blank. The ABR enquiry service returned blank for some name suppressed ABNs and this was not detected during message generation.

o  Analysis has determined that there are four employers that this issue applies to. A workaround is in place to manually populate the employer name field.

·  Contributions for employees with TFNs recorded as all zeroes in the employer database were rejected as this value is not a real TFN allocated to an individual.

o  A remediation process has been undertaken with all employers involved to replace the default values with the individual’s TFN and eliminate this issue.

o  Grant raised that this issue has occurred not only for the SBSCH but also another sender where they are sending through numbers that can’t be validated as a TFN algorithm. This is an avoidable problem. We know there is a way to report in the message that you don’t have a TFN. It seems like the advice the ATO has provided to date is that although people shouldn’t be doing this you will still need to process it.

o  Ty noted that there will be other mechanisms put in place to ensure these TFNs are no longer reported. The ATO would not give advice that this practice should be continued.

o  You can’t change the employers’ payroll systems because of the legitimacy of the information for other purposes. This means that the simplest approach would be that the service provider and clearing house levels are the point which everyone acts consistently and any incorrect numbers get taken out of play.

·  New contributions data for an employer and replacement contributions payment data for the same employer were generated into the same business document. This resulted in two employer context instances for the same employer (same ABN) in the same document. This was rejected by the receiving fund solution as it is not possible using the ABN from the employee’s contribution information, to determine which employer context is the correct one.

o  A guidance note for consideration today.

·  An issue has been identified with the reconciliation of PRNs generated into the contributions message by the SBSCH and the corresponding PRNs supplied by SBSCH through the banking system. The PRN delivered through the banking system is 12 characters in length. The PRN in the message contains six additional leading zeroes to conform to the 18 character PRN requirement of the message. The expected method of adjusting a PRN to the required length is by the addition of trailing spaces.

o  A solution and implementation date for the SBSCH for this issue is being considered and the ATO will provide advice for funds on the matter.

Members noted the paper.

Action item: / 13.5.15-1 / Responsibility:
Due Date: / 10 June 2015
Graham to work with Ian Colhoun out of session to put together a paper regarding the SBSCH issue of contributions for employees with TFNs recorded as all zeroes. / Graham Dawson & Ian Colhoun
Agenda item: / 5
Topic: / SAFF files

Ty spoke to the group on SAFF files.

The following key points were raised in discussion:

·  There was a discussion in the Payroll CIWG.

·  The SAFF was intended to have a single format that funds would accept.

·  There have been issues raised where the number of manifestations of the SAFF has grown.

·  Some funds are refusing to accept the SAFF. They want their own file format. This makes an impossible situation for payroll developers.

·  We shouldn’t be changing anything in the standard SAFF format. You can have the additional database and the optional tuples you can add at the end.

·  SAFF doesn’t conform to certain fund obligations.

·  In the guidance for default values in mandatory fields is an instruction not to populate optional fields. I think we need to emphasise that.

·  Guidance notes around default values apply to SAFF as well as xbrl.

Members noted the paper.

Action item: / 13.5.15-2 / Responsibility:
Due Date: / 10 June 2015
Reconvene out of session to discuss SAFF with interested parties. / Ty Winmill.
Agenda item: / 6
Topic: / EPF/MIG/FVS updates

Ian Colhoun spoke to the tabled paper regarding EPF/MIG/FVS.

The following key points were raised in discussion:

·  There are a lot of conversations going on regarding EPF with testing. The ATO put up a stub and a lot of people have come back and said a stub isn’t best solution for testing.

·  We are negotiating whether we can create multiple stubs on the premise that we would go to each gateway and say pick a fund and we will send you a configured EPF file for that fund to enable you to do an end to end test with at least one of your clients.

·  The SSRG signed off on a revised deployment timeframe for the MIG of October 2016 for all rollover updates v2 and April 2017 for contributions. This is contingent on consultation on outstanding issues (transaction reference number being included, PRN designed for the ATO, how we manage the cut over and change process, service action design and amendments being excluded from rollovers)

·  A MIG will be published in the next week. We will then update the MIG post consultation and publish the final in September.

·  We have been asked to update the picture of where we are going as well as the SBR2 roadmap picture. We are looking at how we can update that at the moment.

·  There is an SSRG paper this afternoon of unscheduled items for signoff on progression of these.

·  We have started getting feedback that the FVS is at risk for 1 July. Shane Moore and Kim Miller are visiting developers regarding this over the next two weeks.

·  1 July is still cut over date at this point. We are actively managing the change process over the next 2 months.

·  There are still a couple of issues in the FVS that the ATO is working on. These are around profile and capitalisation of URLS.

·  We are expecting piloting to commence for the FVS update next week for the first users.

Members noted the paper.

Agenda item: / 7-8
Topic: / BIPs & Guidance compliance process

Ty spoke to the tabled paper regarding the guidance and BIP processes.

The following key points were raised in discussion:

·  There is a draft document of the BIP process with the GOG that was never finalised.

·  We need to look at the guidance process. We need to have a statement around what we expect with guidance.

·  For guidance to be issued it needs to be industry wide. It impacts payload and everyone needs to conform with them whereas BIPs are isolated to gateways for operational specifications.

·  Some operational practices mix into the guidance space which is causing some issues.

·  Ben Mangan joined the discussion to talk through the implications regarding BIP4.

·  BIP 4 changes the way we identify the sender and the receiver in context of the MIG. Currently the legislation ties the obligation to an employer and a fund.

·  Gary raised that one of the main issues with following the MIG is essentially it has the to being the fund and the from being the employer. This means to make the payloads consistent with that all the parts have to go to the same product. You can’t mix parts; they have to go in different ebMS messages. This is not what is currently happening, people are mixing parts.

·  Ian Gibson raised that if you adopt BIP4 in the MIG, it doesn’t stop you from doing anything that you want to achieve as far as he can tell. If you don’t adopt BIP4 it stops a lot of commercial tools from being leveraged for the implementation. So it seems that there was no downside on adopting BIP4.

·  Ty noted that if BIP4 was adopted it was highly unlikely that BIP9 noted in the ASP source assurance paper would be implemented as you would never know who the source employer was.

·  Grant noted that commercial products don’t operate the way the ATO would like them to. Saying BIP4 will not be implemented is not helpful. BIP4 is there for a reason for commercial products. If the ATO feels strongly about capturing the information, there are message properties in ebMS where you can just move those fields into message properties and you can do all the things you would like to do leaving the to and from for the way that the commercial products interoperate and for the way that BIP4 works.

·  We haven’t acknowledged intermediaries in the standard or from a regulatory perspective. Ben was asked, if the source in the from field was a gateway would that cause any issues?

·  Ben noted that unless something is folded into the MIG as documents incorporated by reference into the standard then we cannot enforce it as a requirement. It overlaps with the status of gateway providers and other third party service providers. The SuperStream obligation sits with funds and employers so in terms of what we are looking to enforce, it would have to trace back to the fund and we have looked at the question of what sort of agency relationship arises between parties.

·  There are some parallels as to where this could fit in the framework if there is an inconsistency to what is prescribed in the MIG that is the part of the binding framework that we would keep a focus on from a compliance perspective.

·  There was a conscious decision not to extend the regulatory framework to include third parties.

·  It comes down to grounding this as a requirement of the data standard that is determined by the Commissioner and that means if it was expected to be implemented industry wide within the gateway application role, which the explanatory statement does touch as far as what the gateway provider role is meant to cover, we would need to trace it back to one of the primary entities in the framework.

·  There are other things that need to be considered in order to enable the inclusion of BIP4 into MIG v2 including the impact on EPF.