Decision Proposal 006 - KYC Status

[JamesMBligh]

This decision proposal outlines a recommendation for the handling of KYC Status (as recommended in the Farrell Report). The detail for the proposal is in the attached PDF.

Feedback is now open for this proposal. Feedback is planned to be closed on the 7th September Decision Proposal 006 - KYC Status.pdf

[perlboy]

It may be worth reaching out to the Deloitte team that did some research on this topic: https://www2.deloitte.com/uk/en/pages/press-releases/articles/deloitte-launches-smart-identity-proof-of-concept.html. I believe they spent a fair bit of time discovering just "what is" identity etc that will probably help in model definition.

OpenBankProject has a pretty extensive set of definitions for KYC although they aren't in the PSD2 delivery package: https://apiexplorersandbox.openbankproject.com/?ignoredefcat=true#vv2_0_0-addKycCheck

OpenBankingUK doesn't have a published API for this at this stage as far as I'm aware.

[c-j-hughes]

It was disappointing for KYC not to make it, given all of the use cases it could open up.

The suggested inclusion of an IsActive property for less regulated identity scenarios seems worthwhile.

I suspect this may be a can-of-worms, but... the proposed definition of what it means for someone to be "active" seems a little arbitrary. Does that come from KYC/AML?

We would prefer a different definition, based on how active the user is with the bank, not on whether they performed a financial transaction recently. Shouldn't a recent successful log on, and a review of the account balances make the user active?

The financial transaction seems like it may be misinterpreted when we consider that users have different relationships with accounts. For example, a signatory user may never perform a transaction themselves.

[ghost]

Disclosure - Posted as a member of the advisory committee.

Under AML legislation, an entity is required to hold identification information for 7 years after a relationship ceases.

IsActive could refer to a customer that has been validly identified and holds a current (open) designated service.

As explained to the Committee, suggest AUSTRAC is engaged to provide a steer for the banking industry to the 'on-forwarding/ transmission' of 'credentialled' data (e.g. IsActive property) as banking entities will need to know under the AML/CTF legislation if this is allowed.

Regards

[onereddogmedia]

Would a compromise be to at least provide KYC statuses, along with the IsActive flag? Or is the assumption being made that if a customer has granted access to their data via the API, they have successfully been KYC'ed?

[Pelsurry]

An isActive property could lead to significant issues even as an interim identity flag or preliminary response to the KYC changes proposed in the Review.

Analysis of the type of activity (rather than just the fact of activity) on an account can be more predictive of a ‘real’ entity rather than someone using a synthetic ID for example; particularly for small businesses. Even for use cases less regulated than KYC. Further, each participant is likely to use multiple vectors for ongoing identity authentication and have different standards (depending on the nature of the interaction) for determining “aliveness”.

It is disappointing that KYC didn’t make it into this round of legislative changes. Our understanding is that the proposed changes to regulations that will allow an AML Reporting Entity to rely on another entity’s KYC check is well progressed and in line with international practice.

It will be preferable to wait for clarification from AUSTRAC on how KYC reliance will be implemented in Australia rather than assuming how it might work and including properties to meet an assumption.

[NationalAustraliaBank]

NAB has a number of issues with the recommendation within this proposal which are further detailed below. We require greater clarity on the intent of this proposal and further information on how the 'isActive' flag would be used, particularly within the Banking industry.

In particular, NAB has a fundamental issue with the final premise in this proposal "In the context of the Banking industry the definition of an active customer would be a customer with an open account that has performed at least one transaction in the last 3 months. For this status to be achieved KYC would have been required and the timeframe would minimise the risk of stale information."

This recommendation does not address the Farrell Report Recommendation 3.4 and cannot be safely considered a proxy for doing that. We believe the definition of the 'isActive' flag within this proposal will provide a false sense of assurance and may be incorrectly used by third parties, potentially creating liability issues between data holders and third parties.

There are several other complexities with the proposed definition of an active customer within the Banking industry, including: •Australia’s AML CTF Laws require financial institutions to take a ‘risk-based approach’ to compliance. Therefore, KYC processes and procedures will (and must) differ across different banks, products, services and customer types. •A customer does not need to have transacted in the last 3 months to be Active e.g. Term Deposits can be lodged for up to 5 years, some customers invest cash into a high interest account once and then let it sit there accumulating interest, some loans would have repayments less regularly than every 3 months, etc. •It is possible that there could be some confusion regarding the ‘isActive flag’ in relation to the customer’s profile with the bank. A single customer may have accounts in their personal and business capacity, which may have been subject to different KYC requirements. It is unclear whether an ‘isActive’ flag would be triggered based on transactions for one particular user’s entire profile with the bank, or on a product-by-product basis. •It is consistent with the risk-based approach of Australia’s AML CTF Laws to have some different thresholds for certain low-risk transactions. For example, a login activity to a banking portal, a transfer between linked accounts, or an automated direct debit. In these circumstances, deeming this kind of customer to be ‘active’ and therefore subject to full KYC required for higher risk products would be inconsistent with the intention of the AML CTF Laws. •There are some products, services and customer types that are specifically exempt from KYC requirements under the AML CTF Laws. These include pre-commencement customers and customers obtaining low-risk products. These exemptions are permitted only in certain circumstances. The proposed solution may inadvertently result in entities applying these exemptions from KYC as a general rule to these customers. This would be inconsistent with the intention of the AML CTF Laws in providing these exemptions, and create increased money laundering and terrorism financing risk for banks. •The AML CTF Laws require reporting entities to conduct ongoing, and risk-responsive customer identification processes and procedures. The proposed solution relies instead of a single point-in-time piece of data. It is possible that taking this approach would expose banks to a higher level of money laundering and terrorism financing risk. Further, KYC comprises an entire process, not a single piece of data held by banks regarding their customer. Therefore, isolating and separating the data in this way would purely be be for the purpose of Open Banking and not to meet any other business requirement. We also believe that this is in addition to the CDR principle of providing customers with access to their existing data only. •The Customer Identification Procedures (CIP) adopted by banks are not commonly disclosed in full to customers. This is to prevent criminal activity that identifies these controls, and intentionally bypassing them. Disclosing the proposed solution in this way may create a number of security risks and potential vulnerabilities that could be leveraged for fraudulent activities. •If a customer’s KYC is incomplete or contains errors, a reporting entity cannot always indicate this by simply deeming the customer to be inactive. It is possible that a customer with inconsistent KYC details may have been including whether a customer has been the subject of a suspicious matter report (SMR) to AUSTRAC regarding these irregularities. Disclosure of an SMR, or information that could give rise to an inference that an SMR has been filed, is a criminal offence known as a ‘tipping off offence’. In some circumstances it is possible that while a customer ‘isActive’ a reporting entity may have filed SMRs regarding this customer and incomplete or inconsistent KYC. A reporting entity cannot make this kind of qualification to a customer that ‘isActive’ as that would constitute a ‘tipping off offence’ however if another bank were to rely on the ‘isActive’ label as confirmation that the customer has been appropriately KYC this would not correctly represent the data held on file by the bank for this particular customer and that customer’s risk rating.

[TKCOBA]

From the perspective of leveraging the ID process of other participants, the benefit of the recommended active flag is not clear.

Given AML KYC is partially risk-based, there are a variety of different standards that may be used by different organisations. In this sense, it is difficult to know what standard has been used by an organisation (e.g. what KYC information was collected and verified by a different ADI).

There would need to be a sufficient level of detail to enable one ADI to rely on the ID verification performed by another ADI. Otherwise, all participants would have to agree to minimum standards for KYC information collection and verification.

There is also the issue of confirming that an identity record held by an ADI is being validly claimed by its customer wishing to provide data/information to another ADI.

In this context, and given the potential legal issues, we strongly encourage AUSTRAC involvement in Open Banking to provide direction regarding the on-forwarding of credentialled data. Our view is that the on-forwarding of the following would be desirable (assuming AUSTRAC involvement/support):

1. IsActive

2. Current active product

3. Date identified, and

4. IsIdentified

[bazzat]

The ABA Open Banking Technical Working Group shares the many concerns expressed here about the proposed IsActive flag and the many practical and legal risks it may pose. At the least a much more detailed description of how the flag would operate would need to be provided before we could consider endorsing its use.

[JamesMBligh]

Based on the feedback to this proposal some clarification of intent is warranted.

• The IsActive flag was not intended to achieve the outcomes of supplying KYC status or input data. As stated this would require legislation change of some form and thus could not be brought into the standard until such a change had occurred.

• Some Banks have the concept of a “member” customer. Such a customer would have a customer record and potentially even the ability to login to internet banking but would not have been KYC’ed. Such a customer may be able to participate in the regime even if they did not have any accounts. In this scenario a consumer of the data may misconstrue the existence of a customer record with a Bank as an indication that the customer had been fully vetted by the Bank. This would result in some of the risks articulated in feedback even if the IsActive flag was not included in payloads.

• The concept of an IsActive flag was identified as it would be reasonably transferable to other industries allowing for the Customer record to be generic. Other industries also have the concept of a “member” state or “prospect” state for a customer record.

Based on the feedback provided it is unclear whether the key concerns lie with the appropriateness of the algorithm suggested in the proposal, the risk of misunderstanding of the flag by data consumers or the concept of the flag in its entirety. Further clarification on this point would be helpful from participants.

As this proposal is not a dependency for other pending decisions, there has been feedback from multiple points of view and some clarification would be useful the feedback period for this decision proposal will be extended.

-JB-

[Wil-C]

Disclaimer: This reflects my personal opinion. Offical response via COBA.

• Strongly support guidance from AUSTRAC. • The “IsActive” terminology is a bit confusing and may be misintepreted during implementation. For example, it may be interpreted as an active account rather than a KYC'ed account. • Relying on KYC from another ADI will cause legal liability issue. This has been been reflected by several participants in the Data61 Use Case workshop. Also, an ADI will need conduct its own KYC regardless of whether the previous ADI has conducted or not.

[Pelsurry]

In response to @JamesMBligh, the concern is both with the appropriateness of the algorithm and the risk of misunderstanding. It's clear that the isActive flag can not address current KYC requirements - discussed by @NationalAustraliaBank .

Therefore, in making the following comments I'm thinking about other possible uses (eg indication of fraud or as "prospect" state for a consumer record) and usability for other industries (that may not be reporting entities for KYC purposes for example).

The algorithm is not appropriate for any reasonable use case. The mere presence of activity on an account is not a sufficient test of aliveness. Characteristics of the activity is a more important predictor of aliveness (ie does it fit an historical pattern, does it appear too uniform ie machine generated, does activity occur at an expected location or via an expected device etc). This would apply across industries - simple use of electricity at a home (or payment of an electricity bill) is not a reasonable indicator that someone actually lives at the home.

As an indication of consumer "prospect" state or otherwise indicating that the consumer had not been KYC'ed. As discussed above, ALM regulations currently do not allow reliance. Even if it were a reasonable indicator that the customer had been vetted (or conversely, not vetted ie a prospect), no AML Reporting Entity could rely on it and no other entity should use it to reliably validate identity. Thus, it only functions as some sort of indicator of the "status" of the consumer (as a member or prospect). However, this treatment does not align with the proposed aliveness algorithm.

I can see no reasonable use case for the proposed isActive flag (given current ALM regulations). But there remains a real risk that an isActive flag as currently proposed could be misinterpreted (as discussed in various comments in the thread). Thus there is no obvious benefit from the isActive flag as proposed but a reasonable risk of misuse or misinterpretation.

-JMcKay

[JamesMBligh]

@Pelsurry, is there any concern that a third party consumer obtaining a customer record from a Bank that does not have an indicator of whether that record represents a prospect record (with potentially zero validation) or a full customer (that assumes full KYC) may inadvertently overestimate the certainty of identity that this record provides? I am concerned about this scenario in particular.

-JB-

[Pelsurry]

@JamesMBligh, From a KYC perspective; there is no chance of a mistake given current state of ALM reliance rules. Regulations state that an AML Reporting Entity can only use certain sources for KYC (specifically DVS and credit bureau ) and then only for low-risk entities and must do the verficiation themselves (ie not rely on other to KYC). So an AMl Reporting Entity won’t use any other flag no matter the algorithm or the source.

Therefore the question becomes whether, for some other purpose, a data consumer could confuse a member or prospect customer (who has data extracted via open banking API) for a “real” (in the sense of fully vetted) customer and, as importantly, what is the downside or cost of such confusion were it to arise.

I can’t think of a reasonable case. In the case of fraud detection for example, the proposed isActive flag won’t be a good predictor for reasons already discussed. At best it might be 1 factor used in a ID/fraud check but a fairly weak one.

In any event, assuming we are trying to tag “prospects” or member customers for some reason, then its hard to understand how the proposed algorithm correlates with that state.

Regards, Julie McKay

[JamesMBligh]

I’ll be closing feedback on this tonight. At this stage I will not be moving forward with the IsActive field due to the feedback. If useful scenarios do present themselves in the future, or the absence of such a flag creates problems, then we can always revisit this decision through a new end point version. If there are no issues or use cases then it won’t matter :)

-JB-

[JamesMBligh]

I have now closed consultation on this decision. A recommendation incorporating feedback will be made to the Chair in due course.

-JB-

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document. Decision 006 - KYC Status.pdf

-JB-