Skip to main content
If configured service is to use Australian Credit Header Data as a potential matching source for KYC checks, then there must be an awareness of your obligations under section 35C of the AML/CTF Act 2006. If the full name, address, and or date of birth on file at the credit bureau doesn’t match the details supplied, then the customer must be informed that they have the right to review and update their details with the bureau in question.
Critical Notes
  1. Just because the customer doesn’t have matching data at the credit bureau, doesn’t mean the overall KYC check has failed. It’s just the one possible matching source and is often just an out-of-date address.
  2. This also does NOT mean the customer has failed a credit check of any kind. Checking to see if personal details match those on file at the bureau has zero impact on a customer’s credit history or creditworthiness.

​
How to determine if you have to let the customer know?

There are 2 ways information is passed that a mismatch may have occurred. These will be found in the response from a CreateCheckEntity or UpdateCheckEntity API response (or also in the result of a GET /entity/checks response).

​
In the entityProfileResult clause

Note
The following section will only apply if using entity profiles/recipes.
In the entityProfileResult clause of a response, there’s a section called creditHeaderFailures
Credit Header Failure
In there, there will be name(s) of the bureau(s) that returned a mismatch result. It’s possible for more than one entry to be available in the array if there is more than one credit bureau in the configured source cascade. Valid values include:
  • Equifax
  • Experian
  • others upon request

​
In the checkSummary clause

Note
This following section will apply in all cases
You will find the following keys in the checkSummary clause’s CheckResults Key Value Pair Array: More information on this and other KVPs in the CheckResults array are available here: Understanding CheckSummary Results