Frank, The most authorative information on what is happening is probably from the Australian Federal Treasury website.
The original review of OpenBanking in Australia is available here https://treasury.gov.au/review/review-into-open-banking-in-australia/. The governments reponse to the review which is a consultation process to draft legislation and rules is currently in progress https://treasury.gov.au/publication/p2018-t286983/. This came about because banks would not typically share acustomers financial data when requested by the customer with another bank, mainly to do with loan/mortgage application processing. Another objective may be to put some controls and checks into the consumer credit management industry particularly with regard to an individuals right to access data held by credit reference agencies. Not sure if that's in there. The most advanced part of this process is the legislation which grants consumers the right of access and to some extent control of data held by financial institutions about them https://treasury.gov.au/consumer-data-right/. This chapter from the review summary document (https://static.treasury.gov.au/uploads/sites/1/2018/02/Review-into-Open-Banking-_For-web-1.pdf) is possibly the one of most relevance to GnuCash users and devlopers. "Chapter 5 – Data transfer mechanism Customer data should be transferred via APIs. These APIs should be built in accordance with the Standards. The Australian Data Standard Setting Body, chaired by an independent data specialist, should design these Standards (using the UK’s technical specification as a starting point). The Standards should not mandate specific technology and should not intend to restrict innovation for data transfer. The Standards should enable basic functionality for Open Banking, but they should also be useful for other sectors. Open Banking should not prohibit or endorse ‘screenscraping’, but should aim to make this practice redundant by facilitating a more efficient data transfer mechanism. The starting point for developing the Standards for authorising the transfer of banking data should be a redirect-based model, although a low-friction decoupled approach should also be considered. Banks should not be permitted to create additional barriers for customers using consent (for instance, by restricting use cases) although multifactor authorisation should be considered reasonable as a security measure. Customers should be able to grant persistent authorisation and manage this authorisation transparently. All authorisations should have an expiry date. The Standards should also allow data access for intermediaries such as middleware providers. The Standards should determine the frequency of API calls by third parties (including whether push functionality should be available). Customers who do not use internet banking should still be able to share their data with third parties through service channels which are already offered by their bank. Customers should be able to see their Open Banking interactions. This means participants should be required to maintain a record of data transfers. Participants should also be required to maintain information on API performance to be provided to the regulator if requested." My suspicion is that the standard setting body referred to will primarily be an authorizer of the use of standards rather than a developer of standards as such. My guess is they will adopt something like OFX or its derivatives /successors as a primary data format and then combine that with secure authorization (OAuth2 or similar) and data encryption processes for endpoint to endpoint transmission. The Australian government currently uses a two step authorization process with an initial username/password to logon combined with entry of an authorization code sent to a users specified device.by email and/or SMS. The thought of an Australian government department developing an API does fill me with considerable trepidation even though its development would likely be outsourced. We have had a number of spectacular failures of governments when it comes to specifying and controlling the development of software and its implementation in Australia. Our main federal welfare body developed a Robocop program to detect welfare cheats that was spectacularly successful at demanding money in error from welfare recipients. I have only scanned through the summary at this stage but I will look at the full report in more detail. Usually these things only deal in generalities and it won't be until the specific legislation and associated regulations are drafted that any real digestible information will become available. All this is also taking place against the background of a Royal Commission (Australian equivalent of the inquistion with mental torture rather than physical torture) currently in progress into Australia's Banking Industry which has discovered such unsavoury practices as charging dead people for financial advice they couldn't possibly receive along with giving fairly doubtful financial advice to the live customers amongst other sins. Very generous executive bonuses for directors and executives which they seem to qualify for even when underperforming in a very obvious manner are also under fire. The crop of bank executives who replaced those at the top who resigned have even been voluntarily refusing to accept bonuses, a clear sign of the fear of GOD (Governemnt Organisational Developments). I recently took a brief look at the API specification that the UK was using for VAT submission. There, it seems if you can export a JSON file in a specified format from an accounting program which can be read directly by API based software communicating with the tax office portal using their API then you could meet their requirements. May possibly be more complicated however. I seem to remember MYOB having direct GST(BAS) report submission available to the ATO some 10-15 years ago as an optional extra in Australia. I never used it however as my BAS submission was a 30 sec operation using a webbased portal and MYOB wanted a hefty hike in the annual fee to provide this service. Cheers David Cousens ----- David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
