Consumer Data Right Policy and Engagement Branch
Market Conduct and Digital Division
Treasury
Langton Cres
PARKES ACT 2600

**By email: data@treasury.gov.au**

6 November 2023

Dear Treasury CDR team

**Screen scraping – policy and regulatory implications**

Thank you for the opportunity to comment on the Screen scraping – policy and regulatory
_implications discussion paper._

As an initial observation, this discussion paper has received significant attention amongst our
Members, which is indicative of the importance of the issues raised by the discussion paper
to a broad range of credit providers and other industry participants. As we set out in section
B, there is a diverse range of perspectives amongst our Members regarding the benefits and potential downsides – of screen scraping. For that reason, we conducted a survey of our
Members regarding their experiences and views in relation to both screen scraping and the
consumer data right (CDR). The results of that survey are referenced throughout our
submission and are set out in Appendix A.

We consider that supporters of screen scraping and those who are less comfortable with its
use both raise valid and important points. For instance, the need to ensure that consumers
maintain the security over their personal information is of growing relevance given the
increased activity of scammers, and the risk that screen scraping could result in Australian
consumers being conditioned to hand out personal information inappropriately is a concern
(and should be subject to robust research).

Importantly, there is almost universal support amongst industry participants for the CDR to
potentially be a better, and therefore preferred, means of obtaining data about a customer
that is necessary for lending use cases. However, there are more mixed views amongst our
Members as to whether the CDR is effective enough to currently be a viable alternative to
screen scraping, and what should be done to improve the CDR to make it a viable - or better
– alternative


-----

**A.** **Summary / Recommendations**

1. Screen scraping is a mature and highly valuable data exchange mechanism in the

consumer credit sector.

2. To date, screen scraping has arguably done more to promote the adoption of automated

data-led practices in the lending industry than the CDR (although in a more limited form
of automation than the CDR could provide). For many lenders – particularly smaller,
challenger lenders – it continues to be a very important part of their business processes.


3. Screen scraping is also widely used in the broker market, including to improve

compliance with responsible lending and best interest obligations. This includes where
the ultimate lender does not use it directly, i.e. non-using credit providers also benefit
indirectly from brokers’ use of screen scraping.

4. Accordingly, screen scraping supports competition, innovation and a better consumer

experience compared to more manual forms of data exchange across all forms of
consumer credit, including through the entry of new lenders (particularly in the ‘fintech’
space and those lenders which do not have a significant existing customer base) and the
rise of brokers (particularly in the mortgage market)

5. ARCA and its Members strongly support the CDR. We consider the aim of the CDR to

create a structured, consistent and safe data exchange method that operates across
numerous sectors of the economy is preferable to relying on the more ad hoc screen
scraping model. While the screen scraping model has worked over the last few years,
there should be a focus on moving industry towards the CDR.

6. As noted above, in support of this submission, ARCA surveyed its Members regarding

their experience and views in relation to both screen scraping and the CDR. Rather than
being the formal views of the relevant organisations, the responses reflect the views and
opinions of the respondents in their capacity as credit professionals (primarily coming
from the credit risk area, but also from product and operational risk, compliance and
legal). We have referenced some of the results of this survey in this submission and
include a more detailed summary in Appendix A.

7. The majority of respondents to ARCA’s Member survey (62%) have noted support for

screen scraping to be subject to restrictions/prohibition, either immediately (24%) or
when CDR is a viable alternative (38%).

8. However, there is also a significant number of Members (35%) who do not think that

screen scraping should be restricted/prohibited at all, i.e. as per the original Farrell
report, the benefits of CDR depend on it being able to compete with other data sharing
methods.


9. A significant number of respondents hold the view that the CDR is not currently a viable

alternative to screen scraping for various reasons; 69% of respondents either strongly
disagreed or disagreed with the view that the CR was currently a viable alternative, while
14% either strongly agreed or agreed with that view. The view that CDR is not currently a
viable alternative to screen scraping was primarily related to the CDR consent framework,
however was also due to other factors, including data quality and regulatory complexity
with the CDR.

10. As set out in our previous submissions, ARCA agrees with the view that the current CDR

consent process means that, while the CDR may assist some credit providers’ lending
use cases, it is not currently a viable replacement for other data collections methods,
such as screen scraping.

11. Further, more respondents considered that screen scraping provides a better consumer

experience than the CDR; 45% for screen scraping to 21% for the CDR, and a better
outcome for the credit provider; 45% for screen scraping to 24% for the CDR.


-----

12. As ARCA has observed in previous submissions, the initial CDR implementation often

focused on new, loosely described ‘potential’ use cases, rather than the clearly
understood, common and high-value lending use case. While this has changed in more
recent consultation processes, we consider that the consequences of that initial focus in
the design of the CDR regime and rules continue to inhibit its value for lending use cases.

13. Noting the above comments and those regarding the diversity of stakeholder views

(below), ARCA recommends that:


a. Government reiterate and reaffirm their support for the CDR combined with

comprehensive credit reporting (CCR) to be a viable – and better – alternative to
other data sharing methods (including screen scraping) for consumer lending
purposes, i.e. that the lending use case should be a focus of the CDR
implementation to ensure adoption by industry and provide a straightforward and
trusted introduction to the CDR for consumers (i.e. as the lending use case would
likely be the first experience of the CDR for most consumers).

b. In providing for that support, Government should instruct Treasury, ACCC and

OAIC to undertake the work necessary (across both the CDR and CCR regimes)
to give credit providers consistent and reliable access to meaningful data for
purposes that are reasonably necessary for the provision and management of
credit, while also ensuring there are adequate consumer protections (where those
protections likely need to go beyond relying on ‘informed consent’). See Section
C.

c. Given screen scraping is currently an effective tool for many credit providers and

that there will be a tendency for users to stick with what they currently use,
establish appropriate incentives to adopt CDR (i.e. ‘pull’ factors) and move away
from screen scraping (i.e. ‘push’ factors).[1]

d. Based on the work that needs to be done to make CDR a viable alternative (which

may take several years), not to apply an arbitrary timeline for screen scraping to
be ‘turned off’. Doing so will increase the risk that the work to make the CDR a
viable alternative will be rushed and then subject to additional rework (noting that
current Data Holders, i.e. ADIs, are likely to be required to redo some of their
implementation work to ensure the CDR is a viable alternative and must have
confidence that even more changes will not then be needed).[2]

e. Establish criteria for assessing the success of CDR being a viable alternative to

screen scraping, including benchmarking against the improvements identified in
Section C, and set out a timeline for Treasury to check-in and report on that
progress.

f. Subject to CDR being a demonstrated viable alternative for specific sectors (e.g.
‘banking’), prohibit the further use of screen scraping in that sector (if it is still
being used for that sector in preference to the CDR).

g. Any restrictions on screen scraping should be specific to the relevant sector (e.g.

banking, non-bank lenders, telcos etc) and not apply if the sector is not subject to

1 We note also that significant investment has been made by some credit providers, screen scraping
providers and other businesses to optimise the performance of screen scraping, including, for
example, transaction recognition and categorisation. While this capability does exist in respect of the
CDR, some of our Members are concerned that it will take time to meet the same level of
sophistication that exists for screen scraping. This is particularly the case for smaller lenders who do
not already have a large transactional customer base with which to develop their own capability. This
is a further reason to ensure that any mandated move away from screen scraping is done over a
reasonable period and takes into account all relevant circumstances.
2 This is also relevant to the timeline for the extension of the CDR to non-bank lenders.


-----

the CDR regime. Such restrictions should also recognise any exemptions under
the CDR regime that mean that certain data holders within the sector are not
subject to the CDR regime. For example, the minimum business size threshold
proposed to apply to non-bank lenders will mean that those businesses will not be
subject to the CDR. On that basis, any future screen scraping restrictions applying
to the non-bank lending sector would need to consider that gap in the CDR
model.

h. In the meantime, consider ways to improve the safety of screen scraping, either

through direct regulation of providers or indirect regulation of the end users of
screen scraping (e.g. licensed credit providers). The indirect means would involve
requiring licenced credit providers to comply with documented best practice in
relation to screen scraping (which should then ensure the unregulated providers
of screen scraping services comply with that best practice). This would avoid the
need to directly regulate an entirely new type of entity.[3]

i. Adequate funding be made available to provide economy-wide consumer
education regarding data security.

j. The upcoming review of Part IIIA of the Privacy Act includes in its terms of
reference a consideration of the interaction between credit reporting under Part
IIIA and the CDR, including whether the datasets available under CCR should be
expanded. While the 2014 amendments to Part IIIA that introduced the new
repayment history information (RHI) and consumer credit liability data sets (and,
in 2022, the financial hardship indicator (FHI)) improved the breadth of data
available through the Australian credit reporting system, the system still lags
equivalent overseas jurisdictions. This means that the CDR is potentially required
to have a greater role for lending use cases in Australia than it would otherwise
have if the credit reporting system had a broader range of data. Some of our
Members have noted that, while they are likely to use the CDR (subject to the
other matters discuss in our submission), they would prefer to rely solely on the
credit reporting system if it included that broader range of data. We consider that
this is an important issue to consider further; to what extent should the CDR be
relied upon as a ‘top-up’ to the credit reporting system? We consider that it would
be preferable to increase the breadth the depth of data available through the
credit reporting system (where it is immediately subject to the very strict and
targeted disclosure and use restrictions) to include elements such as balance and
improved repayment reporting (including for credit providers which don’t hold a
credit licence). In addition to the data sets available through the CCR system, we
suggest that the review of Part IIIA should include consideration of whether an
entity could be both a credit reporting body and data recipient under the CDR.

3 This approach could also be used to move licenced participants – and therefore all users – away
from screen scraping when appropriate, i.e. that best practice could be updated once the benchmarks
referred to in 13.e are satisfied so that licensed participants are expected not to use screen scraping
in preference to the CDR once it is a viable alternative. This would be a more flexible way to regulate
the use of screen scraping and would not require a brand new regulatory regime.


-----

**B.** **Diversity of stakeholder views on screen scraping**

14. The question of whether screen scraping should be regulated (or potentially banned) is a

complex issue.

15. There is a diverse range of support amongst ARCA’s Members for screen scraping;

ranging from a desire to see it continue without restrictions indefinitely to being restricted
immediately.

16. We consider that these diverse views are a natural consequence of the broad range of

credit providers that service the Australian consumer credit market, and that it reinforces
the need to avoid taking a blunt approach to restricting or prohibiting screen scraping
without fully understanding all stakeholder views and potential impacts.

17. The opposition to screen scraping from some stakeholders within the credit industry

largely relates to the concern that it increases the fraud/scam risks in the Australian
market by requiring sharing of credentials with third parties.

18. The sharing of internet login credentials with a third party, if managed improperly, could

create a honeypot of data for a fraudster. However, there is view amongst some Members
that the current mainstream providers of screen scraping services utilise secure
processes and, so, the risks of direct losses resulting from a wide scale data breach
should be limited (subject to those processes being in fact secure). (Nevertheless, we
note that it would be appropriate to take further action to reduce this risk, see Section D,
particularly 40(ii)).

19. In addition, some Members have concerns regarding the behavioural impacts of screen

scraping on Australian consumers, i.e. does screen scraping increase the risk of scams
by conditioning consumers to disclose internet banking credentials to third parties (in
contrast to the cyber safety message of never sharing your credentials)? Does it create
broader problems with cyber security and protection of personal information (beyond the
internet banking credentials)?

20. Importantly, we note that credit providers will be impacted by this ‘consumer

conditioning’ risk differently based on their overall type of business, which is probably
one of the reasons for the industry’s diverse views on screen scraping. Providers of
transactional facilities (i.e. ADIs) will be subject to a higher direct risk (i.e. from data
breaches) and also indirect breaches (i.e. higher risk of consumers being scammed due
to consumer conditioning resulting from screen scraping). Considering the current focus
on scams that are causing significant loss to Australian consumers, the concerns of those
ADIs need to be considered carefully and given weight as it is the ADIs’ customers which
will experience the fraud on the ADIs’ transaction facilities.

21. It is arguably not possible to create a regime that makes the ultimate user of screen

scraping (i.e. the relevant credit providers using screen scraping) liable for losses
resulting from the indirect risks of consumer conditioning (as this relates to a general
change in consumer behaviour, rather than the outcome of the provision of specific
screen scraping services). This creates a potential moral hazard as the beneficiaries of
screen scraping may not experience the damage caused by the use of those services.


22. While we understand that some Members have monitored their customers’ perceptions

of screen scraping (e.g. trust or otherwise in screen scraping), we are unaware of any
broad-based studies of how the use of screen scraping affects consumers’ data security
awareness and behaviour. Like the work done in relation to the CDR, we recommend that
the consumer conditioning impacts of screen scraping need to be considered fully,
including through consumer testing, i.e. How big a risk is it? Does the use of CDR instead


-----

of screen scraping materially decrease the risk? What can be done to minimise these
risks?


23. As a separate matter, we also recognise that consumer advocates have concerns

regarding the potential for data to be shared with credit providers – whether through the
CDR or via screen scraping – without the protections that would apply to, for example,
data received through the credit reporting system. In response to this concern, the
exposure draft Competition and Consumer (Consumer Data Right) Amendment Rules
_(No. 2) 2023 propose a prohibition on sharing RHI/FHI through the CDR. As set out in our_
submission to those rules, we do not consider that a prohibition on sharing of specific
forms of data (which can, if used appropriately, otherwise be valuable for the lending use
case) is always the best approach, and other methods of consumer protection against
misuse of that data should be considered.[4]

**C.** **Improvements to make CDR a viable alternative to screen scraping**

24. We recognise the work that has already been done to understand how the CDR could be

improved, and we have therefore not sought to outline in detail the issues that exist with
the CDR. However, to provide context to the observation of many Members that the CDR
may not currently be a viable alternative to screen scraping, we note that our Members
have identified the following as being key improvements required to the CDR:

a. **Improve consent process: through both our survey and ongoing discussions**

with Members and the broader industry, the CDR consent process is a key (and
probably the main) reason why the CDR is not seen as a viable alternative to
screen scraping by many of our Members. In our survey, 62% of respondents
identified improvements to the consent process as being a way to make the CDR
a better replacement for other data collection methods and that this feedback was
even stronger in our discussions with Members. We discuss this issue in further
detail below.


b. **Breadth and coverage of CDR: while not raised as a specific question in our**

survey, Members noted that the CDR does not cover all relevant sectors of the
economy (with superannuation being specifically identified as a gap). Currently,
provided the customer can access that information through an internet account,
screen scraping may be able to access that data (which the CDR is not).[5]

While we recognise the aim to expand the CDR to other sectors across the
economy, this will take time. To be clear, we do not propose rushing the
expansion of the CDR to other sectors. However, we consider that it is important
to recognise that as the breadth of the CDR expands, there is likely to be organic
growth in the use of CDR, i.e. if the credit provider would otherwise be required to
maintain two data collection methods – CDR for data accessible through the CDR
(e.g. banking data) and screen scraping for other data not accessible through
CDR – there is a greater likelihood that they will simply maintain their use of the
existing collection method (i.e. screen scraping). Once they can access most/all
the same data through CDR as they can through screen scraping, they are more
likely to move completely to the CDR.

4 To confirm, this observation is made in relation to the general question of whether the sharing of data
types should be prohibited, rather than the specific RHI/FHI data sets.
5 This is also the reason for our recommendation that any future restrictions on screen scraping be
sector specific, see 13.f.


-----

In a similar vein, there is the potential to make the CDR a better alternative to
screen scraping (rather than be merely a viable alternative) by giving access to
additional data sources not accessible via screen scraping, such as monthly ATO
payroll data (i.e ‘Single Touch Payroll’ data).

Our survey asked Members which data would be of most assistance if made
available through the CDR.[6] While our survey did not ask for Members to rank the
importance of the data sources, the following list is in rough order of what we
understand to be most important (based on the frequency with which the data
source was identified and other discussions with Members):

-  ATO data for income verification, including:

`o` Single Touch Payroll Data (as noted by a Member, “in its rawest

format to determine overtime, bonuses, excess superannuation
etc”)


`o` Data available to assist lending to self-employed persons (ATO

notice of assessment and income tax return) and small businesses
(BAS statements)

-  Superannuation data

-  Centrelink data

-  Credit facility data, such as fixed term expiry, base rates/margins etc[7]

-  Improved data to validate identity and meet AML and VOI requirements
(whether or not that involves returning data or simply providing an
indication of validation)

-  Real estate and vehicle registration data

-  Mobile phone number ownership (which should come with telco
involvement in the CDR, although could potentially be incorporated into
CCR as an account number).

One respondent also noted some functionality improvements, including “ability to
pull multiple accounts in one go, catagorisation, red flags for credit risk insight
(dishonours, gambling, debt collections, SACC loans etc)”. We consider that
these would be valuable for lending use cases, although it is relevant that such
functionality is likely to involve value-added data (and, in the case of red flags,
sensitive data). There was support for the ability to close a credit card with
another provider (which, we assume, will come with the action initiation changes).

c. **Improved rules for comingling of data, i.e. covering CDR, credit reporting**

**information and other personal information: credit providers collect**
information to support their lending from multiple sources. Depending on the
source of the information it will be subject to different regulatory requirements,
which impose different rules relating to permissible uses, disclosure and
retention. The effort required to ‘tag’ each element of data with its source (and
therefore restrictions) is significant and, potentially, not possible. Further, use of
the data is likely to involve combining the data to derive other information. In
which case, the resulting derived data may be subject to multiple potentially
inconsistent regulatory regimes. We note that rules to give effect to ARCA’s

6 Assuming all other necessary changes are made to the regime to make it a viable alternative.
7 We note Members referred to improved data regarding credit facilities. However, we understand that
some of that information would be available through the CDR and that the real need is for that
information to be available through the credit reporting system.


-----

standardised consent process may be able to address the issues (i.e. be applying
the same rules/restrictions to the CDR data as would apply to credit reporting
information).

d. **Improved data received through CDR: while not asked as a specific question in**

our survey, some Members who currently use the CDR have reported that the
data received through the CDR is not as complete as expected. See, for example,
the comments summary for questions 6, 11 and 14. A Member has noted that, in
some cases, the data holder did not return data for all accounts held with the data
holder. Some of our Members have also reported that the data obtained through
screen scraping is generally more complete, accurate and in a useable form.

25. Other than the matters above, a smaller number of respondents (24%) identified the

general level of resources needed to support CDR use, including IT, risk/ compliance/
legal etc. ARCA also has a general concern regarding the overall complexity of the CDR
and considers that it is not possible for any small (and many, medium-sized) credit
providers to directly participate as an accredited data recipient.[8] We expect that this
concern has become somewhat lower for Members given the improved ability under the
CDR representative rules which better allow for indirect participation. Or, possibly,
Members have not yet had enough experience with the regime to identify its significant
(and potentially unworkable) complexity as only 21% had participated in the CDR and
83% responded ‘None/Not sure’ when asked ‘What model do they use or would probably
use to access data through the CDR regime?’.

26. In addition, some Members noted that there were differences in the consistency of data

holders’ processes in relation to the authentication flow. Such differences could create a
poorer consumer experience and increase the risk of consumers dropping out of the
process. We note that the authentication uplift review would be relevant to this issue.

27. We consider that these improvements must be made with the lending use cases explicitly

in mind. We acknowledge and support the work that has recently been done to improve
the CDR more broadly, including the CDR Consent Review. However, as noted in our
submission to the consent review, we do not think those improvements go far enough or
are targeted enough to improve the CDR so that it will move credit providers away from a
known and trusted source of data (i.e. screen scraping). In fact, as noted in our
submission, some of the changes, such as the recommendation to introduce deidentification and deletion by default, will make things worse for credit providers.

_Improving the consent process_

28. As we have noted in previous submissions in relation to the CDR, we do not consider that

the consent process fully supports the use of the CDR for lending use cases. This is
partly the result of the consent process creating a more complex consumer experience
(compared to the simple ‘one tick box’ approach for screen scraping). While we
acknowledge that the CDR consent process helps to promote the giving of ‘informed
consent’, it is problematic if the process complexity creates a poor consumer experience
that turns consumers off the CDR completely. As one respondent noted, “[the CDR
consent process is] long, complicated and intimidating for consumers”.

29. However, the problems with CDR consent go beyond the complexity of the process. The

very nature of the ‘voluntary, express, informed, specific as to purpose, time limited and

8 As noted in our submission to the CDR Consent Review, the proposals in relation to ‘dark patterns’ is
another example of where direct participation in the CDR could become beyond the capability of any
but the largest credit providers.


-----

easily withdrawn’ consent requirements are problematic when seeking to obtain and use
information for lending use cases. Credit providers need certain and consistent access to
data and permissions for using that data. They must know the data sets that they will
receive, the purposes to which they may put the data, and the circumstances in which
they may retain the data for subsequent use.[9] The CDR consent process provides none
of that certainty or consistency as consumers can opt-in or out of the various consent
elements – and change those consents at a later time. While the proposed ability being
considered by the CDR Consent Review to bundle consents will help, it will not resolve
the problem. For example, the proposals will not give credit providers the certainty
needed in relation to data retention (and the move to de-identification and deletion by
default will cause additional problems).

30. ARCA’s recommendation for the development of ‘standardised consents’ as set out in our

earlier CDR submissions will help to address the concerns of credit providers if properly
supported through the CDR Rules. Essentially, the use of such standardised consents –
which establish with certainty the data sets, use and disclosure purposes and
deidentification/deletion requirements – moves away from the ‘anything goes with
consent’ approach adopted by the CDR towards the ‘permissible/prohibited’ approach of
the credit reporting regime under Part IIIA of the Privacy Act.[10]


31. Importantly, we note that the use of standardised consents could include some of the

restrictions that would apply to data received through the credit reporting system, such
as the prohibition on using the data for marketing purposes. We consider that this would
help to address the concerns raised by consumer advocates described in 23.

**D.** **Improvements to screen scraping**

32. As noted in the Summary, we consider that credit providers should eventually stop using

screen scraping once the CDR is a viable alternative, and – if they do not do so voluntarily
– it should be restricted or prohibited through regulation (subject to our observations in
13.g).

33. However, screen scraping is still likely to be a valuable data exchange mechanism for

several more years, and we consider that additional regulation of the service may be
appropriate.

34. This regulation could be achieved through:


a. Direct regulation of screen scraping providers, e.g. licensing and general conduct

obligations, including security, data handling and CX requirements that reflect
best practice; or


b. Indirect regulation through imposition of requirements on licensed credit

providers when using screen scraping services, i.e. licenced credit providers
must only use the services of screen scraping providers that meet documented
best practice.

35. We note the benefit of the second approach of indirect regulation is that it would form

part of the existing NCCP licensing regime and avoid the need to create an entirely new
type of regulated entity. While an unregulated screen scraping service may also offer
services to non-licensed entities, the fact that a significant part of its business is offered

9 Which is why the credit reporting system is based on a notice process, rather than consent.
10 As we have noted in our previous submissions, a credit provider could still obtain further consents
outside the standardised consent process if necessary for their particular circumstances (which is
consent with the purpose of the CDR to support innovation).


-----

to licensed entities would ensure there is a strong incentive to satisfy any best practice
requirements are imposed on those licensed clients.

36. Relevant to the question of how to regulate screen scraping on an interim basis, is that

there appears to be a limited number of screen scraping services used by the credit
industry. In our survey, Members that use screen scraping services, reported a total of 5
service providers being used (the list of servicers named by our Members will be
provided to Treasury separately).


37. In addition to the survey results, some of our Members consider that the mainstream

providers already have strong IT security policies and procedures in place, which have
been subject to continuous improvement of the last few years. That suggests that those
service providers are already seeking to pursue a ‘best practice’ approach, and would
not object to that approach being documented and enforced.

38. We consider that the best practice requirements could address many of the matters that

are covered in Part IIIA of the Privacy Act (in relation to credit reporting) and CDR rules
as to consent/notice, data access, use and disclosure, and other relevant consumer
protections. However, to be clear, we would not recommend simply replicating the
approach from those existing regime, particularly those from the CDR regime. For
example, we do not recommend simply applying the Privacy Safeguards from the CDR
regime to screen scraping data. As noted above, the overly strict design of the CDR rules
(particularly in relation to consent and its impacts on data access and use permissions) is
one of the main reasons why the CDR is not currently seen as a viable alternative to
screen scraping by many Members.

39. To the extent that some of the problems with the CDR are addressed through our

proposal for ‘standardised consents’ (as described above), the same consents could be
applied to screen scraping as best practice.

40. We consider that documented best practice would cover the following matters:

i. **Consent, data access, permitted uses and disclosure, and data retention: a**
similar approach to developing ‘standardised consents’ for the CDR regime (as
discussed above) could address these matters. That is, the licenced credit provider
and/or provider of the screen scraping services would use a standardised consent
that establishes the types of data that is accessed, how that data is handled, used,
disclosed, deleted/deidentified etc. The development of such standardised consents
would balance the interests of the credit provider with the need to protect the privacy
of the individual.

ii. **Responsibility for security breaches: ASIC’s 2022 update to the ePayments code**
clarified the question of liability as between the consumer and the subscriber (i.e. the
provider of the account which is ‘scraped’) for losses caused by the consumer’s use
of screen scraping services. However, there is less clarity on the liability as between
the consumer and the provider of the screen scraping service/relevant credit provider
in the case of a security breach of the service provider/credit provider. As noted
above, we understand that the practices of mainstream providers of screen scraping
services mean that such security breaches are unlikely and that direct losses arising
from any breach (i.e. theft of the consumers’ funds from a ‘scraped’ account) would
be limited.[11] Nevertheless, given the significant disruption to consumers and account

11 Almost all ADIs would use two factor authentication for transactions done through internet banking
which significantly reduces the risk that a data breach would result in direct fraud losses (although the
potential for credential stuffing – where the consumer reuses the credentials for other services – also
raises a risk). The greater direct risk is likely to be in the misuse of the detailed personal information
that could be visible to the fraudster through the customer’s internet banking service.

10


-----

providers that a large-scale breach could cause, we consider that the documented
best practice should set out further expectations if any security breach occurs. For
example, what steps would the service provider/credit provider take in the case of a
breach to minimise the potential impact of the breach to the consumer and to the
account provider? What would they do to limit the risk of identity-takeover from such
a breach? What warranties does the service provider/credit provider offer to the
consumer when providing/recommending the use of the screen scraping service?

iii. **Data security: the documented best practice should establish appropriate data**
security expectations. As noted above, our Members have observed that mainstream
providers of screen scraping services generally maintain stringent data security
policies and practices. To establish what best practice looks like, we expect those
providers could provide the initial views on what is appropriate. This best practice
should cover off whether access can be ongoing (rather than once off/time-limited)
and if write access should be allowed. We note that for lending use cases, read-only,
once-off/time-limited access is generally required, and we have concerns regarding
use cases that would require an ongoing or write access through screen scraping.

iv. **CX guidelines: in the CDR regime, the importance of a consistent, clear consumer**
experience to promote consumers’ trust in, and use of, CDR has been recognised
from the start. While establishing best practices CX guidelines for screen scraping will
never completely remove the risk of screen scraping services causing behaviour
changes/consumer conditioning, we consider that such guidelines – if informed by a
robust consumer research, could reduce the risk.

41. As a separate matter, we understand that some ADIs have implemented technological

steps to block access to their internet banking services by providers of screen scraping
services. We do not make any observations on whether this is an appropriate step.[12]
However, if the above best practice approach is implemented, and subject to any
technological limitations, it could be appropriate for ADIs to take steps to block any
screen scraping by providers which do not adhere to those best practice steps.

If you have any questions about this submission, including our Member survey, please feel
[free to contact me on 0409 435 830 or at mblyth@arca.asn.au.](mailto:mblyth@arca.asn.au)

Yours sincerely,

**Michael Blyth**
General Manager – Policy & Advocacy

12 However, we do note that this means that credit providers using screen scraping services must take
work-around steps which can involve more manual ways of collecting data, such as through OCR
scanning of bank statements; which, itself, creates data security risks.

11


-----

**Appendix A**

**ARCA Member use of Screen Scraping and Consumer Data Right survey**

**Background**

To support ARCA’s submission to Treasury’s Screen scraping – policy and regulatory
_implication discussion paper, we surveyed our Members regarding their experience and_
views in relation to both screen scraping and the CDR. Rather than being the formal views of
the relevant organisations, the responses reflect the views and opinions of the respondents
in their capacity as credit professionals (coming from various areas, including credit risk,
product and operational risk, compliance and legal).

We received 29 completed surveys. It should be noted that, given the nature of the survey,
this could include responses from multiple individuals within a single Member. As the
respondents come primarily from the credit risk areas within our Members, it should be
acknowledged that this would influence the views of those respondents (and that
respondents from other business areas may have a different perspectives on screen
scraping and the CDR).

Overall, the issue of screen scraping (and, particularly, how it compares to the CDR)
received significant attention amongst our Members. We consider that this shows the
importance of the issues to a broad range of credit providers and other industry participants.

The results are set out below. We gave respondents the opportunity to provide a comment in
relation to each question and have summarised those comments where relevant. Where we
think a comment is particularly informative, we have included the verbatim comment.

12


-----

**1. Which of the following best describes your business?**

|Value|Percent|Count|
|---|---|---|
|Larger ADI (majors and larger regional banks)|41.4%|12|
|Other ADI|31.0%|9|
|Non-ADI|27.6%|8|
||Totals|29|


Non-ADI

28%

Larger ADI (majors

and larger regional

banks)

41%

Other ADI

31%


13


-----

**2. Which best describes your current role in your business?**

|Value|Percent|Count|
|---|---|---|
|Credit risk|51.7%|15|
|Operations|10.3%|3|
|Product|10.3%|3|
|Op risk, compliance or legal|17.2%|5|
|Other|10.3%|3|
||Totals|29|


Other – please

describe in

comments

10%

Op risk, compliance

or legal

17%

Credit risk

52%

Product

10%

Operations

11%


14


-----

**3. Status of screen scraping in your business?**

|Value|Percent|Count|
|---|---|---|
|We currently use it|62.1%|18|
|We have used it before but don’t now|13.8%|4|
|We have never used it|17.2%|5|
|Not sure|6.9%|2|
||Totals|29|


Not sure

7%

We have never

used it

17%

We have used it

We currently use it

before but don’t

62%

now
14%


**Comments summary:**

-  Respondents noted the following:

`o` _We have used in a proof-of-concept type basis but no longer use._

`o` _Our main brand does not use it but purchased subsidiaries are likely to use it_

`o` _We heavily rely on this service to provide loan services to our customers._

`o` _I've also implemented screen scraping in a prior business where we only allowed_
_screen scraping (we didn't allow customers to upload payslips and provide_
_statements)_


15


-----

**4. If you use/have used screen scraping, for what purpose(s): (Pick any that**
**apply)**

|Value|Percent|Count|
|---|---|---|
|Credit related: pre-fill application|24.1%|7|
|Credit related: verify financial (e.g. income & expense) details|72.4%|21|
|Credit related: credit scoring/credit worthiness assessment|34.5%|10|
|Other: provision of personal financial tools|6.9%|2|
|Other – describe in comments|3.4%|1|
|None/Not sure|24.1%|7|


80

70

60

50

40

**Percent**

30

20

10

0

Credit related: Credit related: Credit related: Other: Other – None/Not sure

pre-fill verify financial credit provision of describe in

application (e.g. income & scoring/credit personal comments

expense) worthiness financial tools

details assessment


**Comments summary:**

-  One respondent noted that screen scraping had also been used to for a “round up app to
round up every day transactions and help people payoff their loans faster”.


16


-----

**5. If you use/have used screen scraping, which business provided the service:**
**(Pick any that apply)**

[We will provide this information to Treasury separately.]

17


-----

**6. Status of CDR in your business (as a recipient/user of CDR data)?**

|Value|Percent|Count|
|---|---|---|
|We currently use it|17.2%|5|
|We have used it before but don’t now|3.4%|1|
|We have never used it|69.0%|20|
|Not sure|10.3%|3|
||Totals|29|


Not sure

10%

We currently use it

We have used it
17%

before but don’t

now

4%

We have never

used it

69%


**Comments summary:**

-  One respondent noted that they were currently looking to achieve accreditation. Another
respondent noted that it had been used only in a pilot.

-  One respondent provided a detailed comment that set out their view that the CDR remains
immature and is not a workable substitute for many screen scraping use cases, especially for
important use cases relevant to lenders. They noted concerns with the consent process, data
quality issues (and the importance of data integrity to credit providers given the risk of credit
losses and responsible lending requirements), accreditation burden and regulatory concerns
with the treatment of CDR data (and how that is inconsistent with business practices).

18


-----

**7. If you use/have used CDR data, for what purpose(s): (Pick any that apply)**

|Value|Percent|Count|
|---|---|---|
|Credit related: pre-fill application|6.9%|2|
|Credit related: verify financial details|10.3%|3|
|Credit related: credit scoring/credit worthiness assessment|6.9%|2|
|Other: provision of personal financial tools|6.9%|2|
|None/Not sure|82.8%|24|


90

80

70

60

**Percent** 5040

30

20

10

0

Credit related: Credit related: Credit related: Other: provision None/Not sure

pre-fill application verify financial credit of personal

details scoring/credit financial tools

worthiness

assessment


19


-----

**8. What model do you use OR would probably use to access data through the**
**CDR regime?**

|Value|Percent|Count|
|---|---|---|
|Authorised data recipient yourself|41.4%|12|
|CDR representative (of an authorised data recipient)|10.3%|3|
|Trusted adviser|3.4%|1|
|None/Not sure|44.8%|13|
||Totals|29|


Authorised data

recipient yourself

None/Not sure

42%

45%

CDR representative

(of an authorised

Trusted adviser data recipient)

3% 10%


**Comments summary:**

-  One respondent noted that they would ideally like to use CDR solutions through their current
screen scraping providers.

20


-----

**9. Overall, which do you think currently provides the better consumer**
**experience:**

|Value|Percent|Count|
|---|---|---|
|Screen scraping|44.8%|13|
|Consumer data right|20.7%|6|
|About the same|10.3%|3|
|Don't know|24.1%|7|
||Totals|29|


Don't know

24%

Screen scraping

45%

About the same

10%

Consumer data

right

21%


**Comments summary:**

-  Comments from respondents generally focused on the CDR consent process (which is
reflected in our comments in our submission). One respondent noted that it was “long,
complicated and intimidating for consumers”. That respondent noted anecdotal feedback that
flow completion rates for CDR consent are substantially below screen scraping.

-  One respondent noted that there needs to be standardisation between ADIs (i.e. as account
holders).

-  One respondent did recognise that “CDR would in the long run provide a better customer
experience but we will still need screen scraping in the short term for coverage”.

21


-----

**10. Overall, which do you think currently provides the better outcome for**
**your business?**

|Value|Percent|Count|
|---|---|---|
|Screen scraping|44.8%|13|
|Consumer data right|24.1%|7|
|About the same|6.9%|2|
|Don't know|24.1%|7|
||Totals|29|


Don't know

24%

Screen scraping

45%

About the same

7%

Consumer data

right

24%


**Comments summary:**

-  The comments covered a broad range of issues, including:

`o` Credit providers being strong advocates for a simple, effective Open Banking regime
to supplant screen banking (which was originally promoted as a way to address
competition concerns), and that “most lenders would eagerly abandon screen
scraping and become enthusiastic adopters of a mature CDR regime”.

`o` Concern that current providers have advanced working solutions for categorisation of
transaction data received through screen scraping and value added insights, and that
this would not be the case with CDR.


22


-----

Concern that “CDR data is not as clean as transaction data and so categorization and
mapping is more challenging”.

CDR will provide a better solution in the long run but in the meantime both methods
were needed.

Noting that the fact that screen scraping breaches the terms and conditions of most
account providers was not a good outcome for the business, and that the CDR is
more “robust and easier to systematise”.

23


-----

**11. Do you support restricting/prohibiting use of screen scraping? (Pick the**
**best answer)**

|Value|Percent|Count|
|---|---|---|
|Yes – immediately/very soon (across all sectors)|24.1%|7|
|Yes – but only when CDR is a viable alternative (on a sector- by-sector basis)|37.9%|11|
|No – the benefits of CDR depend on it being able to compete with other data sharing methods|34.5%|10|
|Don’t know/no view|3.4%|1|
||Totals|29|


Don’t know/no

view

3%

Yes –

immediately/very

soon (across all

No – the benefits sectors)

of CDR depend on 24%

it being able to

compete with

other data sh

35%

Yes – but only
when CDR is a

viable alternative

(on a sector-by
sector basis)

38%


**Comments summary:**

-  The comments were mostly against restricting/prohibiting use of screen scraping (at least in
the near term) and provide a good insight into respondent’s views:

24


-----

_Compelling non-bank lenders to use the current iteration of the CDR would lessen_
_competition in lending markets._

[This respondent provided a detailed description of the impact on non-bank lenders
and smaller ADIs, including a view that given the poor take up of CDR by consumers,
the credit providers would be forced to make onerous data requests of loan applicants
(whereas major banks are less likely to as they often hold the transactional
relationship), absorb higher fraud losses due to the unreliability of paper and
electronic bank statements, and find it more difficult to compete with major lenders.]

_CDR needs to be not only viable but provide on-par (or better) information for the CP_

_I find it fascinating that all banks state in their terms and conditions to not share IB_
_credentials but then ask to share them for the purpose of screen scraping._

_I get that CDR has one major benefit over screen scraping, that being not sharing_
_internet banking credentials however that seems to be it. Which only really address_
_one risk (security) however until all the other business risks (licenses, regulation,_
_responsible lending, credit risk, operational costs and efficiency, fraud) are met at_
_least equally by the CDR solution the benefit to customers. industry and regulators in_
_banning screen scraping just doesn't seem to stack up_

_CDR needs to provide a lot better quality data before this would be something to_
_consider._

_I don't support the prohibition of this option as it is relatively low cost in comparison to_
_the costs involved in transitioning to CDR. The user experience is simple and easy._

_We will need screen scraping to remain for years to come until CDR has the_
_coverage we need._

25


-----

**12. To what degree do you agree with this statement: The CDR is currently a**
**viable replacement for how we currently collect/verify an applicant’s financial**
**information when assessing a loan (whether that is screen scraping or other**
**collection methods).**

|Value|Percent|Count|
|---|---|---|
|Strongly disagree (no, it is not a viable replacement)|48.3%|14|
|Disagree|20.7%|6|
|Neutral|10.3%|3|
|Agree|10.3%|3|
|Strongly agree (yes, it is a viable replacement)|3.4%|1|
|No View|6.9%|2|
||Totals|29|


Strongly disagree

(yes, it is a viable

replacement)

4% No View

7%

Agree

10%

Strongly disagree

(no, it is not a

Neutral

viable

10%

replacement)

48%

Disagree

21%


26


-----

**13. Regardless of how you answered [the previous question], which of the**
**following would make the CDR a better replacement for other data collection**
**methods when assessing a credit application? (Pick up to three)**

|Value|Percent|Count|
|---|---|---|
|Improve consent process|62.1%|18|
|Improve consistency of data holder processes|44.8%|13|
|Don’t allow customers to opt-out of legitimate and necessary purposes, including deletion/de- identification|37.9%|11|
|Give certainty to CP to access all the relevant data, e.g. all accounts and data sets|58.6%|17|
|Improved rules for comingling of data, i.e. covering CDR, credit reporting information and other personal information|44.8%|13|


70

60

50

**Percent** 4030

20

10

0


27


-----

|Simplify accreditation process|3.4%|1|
|---|---|---|
|Reduce the overall resources needed to support CDR use (e.g. IT, risk/ compliance/ legal etc)|24.1%|7|


**Comment summary:**

-  One respondent noted that larger banks have sufficient transactional data from the customers
to use behavioural scoring techniques to build Probability of Default models. Those models
can then incorporate CDR data to assist with automatic approvals of loan applications.
Smaller lenders do not have that pool of transaction data (nor the resources to do the
analysis) and rely on credit reporting bodies (CRB) to develop those types of models. The
respondent noted that a solution could be to allow the CDR information to be integrated into a
CRB enquiry so that the CRB could use the data to build those models, which would be
particularly useful for borrowers with a limited credit history (e.g. young people, people with
low income, recent migrants etc). This could, in turn, improve financial inclusion and
potentially lower the cost of credit for those consumers.

-  One respondent noted that the coverage of the CDR needed to be broad and cover all ADIs
and non-ADIs.

-  One respondent noted that the data, specifically living expense categorization, needed to be
aligned to credit provider general living expense categories.


28


-----

**14. Further to [the previous question], are there any other reasons why you**
**would use screen scraping over CDR or are there other ways to improve the**
**CDR?**

**Response**

n/a

The potential harms associated with screen scraping have been overstated: ○ Screen
scraping has been the predominant form of bank data capture and aggregation globally for
over 15 years. Despite scaremongering, we are not aware of any reported instances of
credential leaks from reputable, scale providers of screen scraping services ○ To address

specific concerns, higher-risk activities undertaken by some screen scraping vendors, such
as the storing of bank login credentials (whether encrypted or not), could be prohibited

Processes already established, confidence in the data quality and the interpretation of the
data like transaction categorisation, red flag creation

no

Multi sector - some industries not yet sharing data

I would not use screen scraping over CDR. CDR can be the holy grail for responsible
lending.

Formatting and presentation of screen scraping data I have seen is better fit for purpose for
lending/serviceability.

Also allow the current solution providers of screen scraping technology to be data recipients
and service providers to ACL holders which will remove the cost to change for industry

Have provided suggestion for improving the CDR data that would avoid the need to rely on
data scrapping services.

NA

Data standard akin to ARCA DS and minimum SLA requirements on data providers (e.g. API
response times and outages).

better customer experience (easier consent)

I'm not sure if it is an issue, but if we did the investment to use CDR then it would ideally be
completed for every application, i.e no option to opt-out. Would this approach cause any
regulatory / consumer rights type issues, or create reputational risks?

CDR doesn't currently capture the same volume of lenders that screen a scraping does
currently


29


-----

None

None, if data was appropriate for end use.

No

Consumer education and uptake of CDR needs to significantly improve.

Weighing up an existing and mature service over one which is still developing, has data /
consent / legal issues. Lots of upside or CDR in consent, data quality, legal rules consistent
with CCR, ongoing maintenance being easier.

No

No

Cost, ease of use, system integration and less complexity when compared with CDR.

N/A

It seems more efficient

No

We will continue to use screen scraping to get full coverage of data.

ADIs can control the competitive of the credit provision environment through strategic
access / availability of data

We dont use screen scraping

None that I'm aware of


30


-----

**15. What types of data would be of most assistance if made available through**
**the consumer data right (assuming all other necessary changes are made to**
**the regime to make it a viable alternative).**

**Please list the 2 - 4 types of data that would be most beneficial in your credit**
**management processes (with any further explanation that you think would be**
**helpful). Examples could include: ATO monthly payroll data; ATO notice of**
**assessment; superannuation data; vehicle registration data.**

**Response**

ATO monthly payroll date ATO NOA Superannuation Data

-  ATO data to assist with income verification of individuals (ATO monthly payroll data) - ATO
data to assist with income verification of sole traders/self-employed persons (ATO notice of
assessment and income tax return) - ATO data to assist with income verification of small
businesses (BAS statements)

Superannuation data, ATO data, centerlink data for income verification

ATO monthly payroll data social security payment data

Financial data

-  Single Touch Payroll data (need payroll data in it's rawest format (to determine overtime,
bonuses, excess super contributions etc)) - Credit Facility data (actual repayment, base interest
rate, margins, data to determine remaining term for distinct periods e.g. if fixed then remaining
fixed term and total remaining term). Required to accurately calculate worst case repayments
for serviceability purposes. - There should be a single source system to validate identity and
meet AML and VOI requirements. Banks could help fund a single system rather than all try and
interpret complex rules and design their own systems.

ATO monthly payroll data ATO notice of assessment

Within banking transaction data: Ability to pull multiple accounts in one go, catagorisation, red
flags for credit risk insight (dishonours, gambling, debt collections, SACC loans etc)  Other
data: ATO payroll/NOA/ITR Ability to close a credit card with another provider as part of a debt
consolidation loan Balance in CCR

Transaction categorisation to create personal budget Credit facility details including interest
rate, repayments and outstanding balance (not captured within comprehensive credit reporting
regime) ATO income information

ATO monthly payroll data; ATO notice of assessment; superannuation data; vehicle registration
data.

-  Income tax returns/notice of assessments - crucial for self employed borrowers - Mobile phone

31


-----

number ownership e.g. phone number owner and time number has been registered under
owner.

ATO monthly payroll data, ATO notice of assessment and ATO tax return data (especially
around income including rental income and also rental expenses).

1. ATO notice of Assessment to verify declared income amount 2. ATO monthly payroll data to
verify income amount and the borrower remains employed. Also used to pre-populate the
employer and income amount in an online application process. 3. Just generally being able to
validate borrower identity information against Government databases to reduce fraud and to
improve customer risk assessment processes. This doesn't have to be returning data to us, but
can be receiving a 'tick' that the information is validated against these databases. 4. Real
property data from the state governments, used to pre-populate and verify ownership of houses
and other property. Ideally also provided is the actual property address, in addition to the
lot/plan and title reference type information.

ATO reported income/payroll and superannuation data. ATO notice of assessment. Vehicle
registration. Titles information.

Payroll Data, Transactional Data

ATO data

ATO monthly payroll data ATO notice of assessment Centrelink benefits data

Government sources - ATO payroll, ATO notice of assessment, Centrelink, superannuation.

ATO data for income verification, standardised data sets from banks

Bank statements Notice of assessment Vehicle registration data Address confirmation

ATO DATA

Transaction data

ATO payroll,

Payroll NOA All Credit cards, mortgages from all types on non-bank institutions.

ATO monthly payroll data and vehicle registration data

ATO notice of assessment Income data of applicant Changing Personal Income, Primary
Identification Requirements


32


-----

