Credit Reporting Privacy Code 2020 — a practical guide for collections teams

The Credit Reporting Privacy Code 2020 is a code of practice issued under the Privacy Act 2020. It modifies how the information privacy principles apply to credit reporting, and it binds both credit reporters and the subscribers who use their data. For a collections team, it is the single most operationally relevant privacy instrument there is: it determines when you may look at a credit file, what you may do with what you see, what you may report back, and what you must be able to show if the debtor complains.

Permitted access, not general access

The starting point is that credit information is not a general-purpose dataset. Access is tied to a permitted purpose and to a subscriber agreement with the credit reporter. Typical permitted purposes include assessing an application for credit, reviewing an existing credit arrangement, and collecting an overdue payment on an account you own or are instructed to recover.

Two consequences follow, and they are the ones teams most often get wrong. First, the subject of the enquiry must be the person on the account. Checking a debtor's partner, flatmate or employer because they are easier to find is not a permitted purpose. Second, the account must actually be overdue. Pre-emptive checks on a current account, made because a payment looks likely to be missed, are not collections access.

Guarantors and joint accounts

A guarantor's liability is contractual, and access to their credit information depends on the basis on which they were assessed and the terms they agreed to. Do not assume that access to the principal debtor's file extends automatically to a guarantor, or that a joint account holder can be checked in relation to the other holder's separate debts. Record the basis in each case.

Accuracy and the correction obligation

The Code carries strong accuracy duties. Before using credit information to make a decision, the user must take reasonable steps to ensure it is accurate, up to date, complete, relevant and not misleading. In collections, that duty has a practical edge: matching the file to the person is the accuracy step that matters most. A common name, an old address and an approximate date of birth produce mismatches, and a mismatch in collections means demanding money from someone who does not owe it.

When an individual seeks correction, the request must be dealt with, and if the correction is not made, a statement of the correction sought must be attached to the record. Operational translation: your workflow needs a dispute state that halts escalation, not a note in a comment field that the next collector will not read.

Defaults, notice and retention

Reporting a default is a serious step with a long tail for the individual. The Code imposes conditions on when a default may be reported — including notice to the debtor and minimum age and amount thresholds — and limits how long default information may be retained and disclosed. These conditions have been amended over time, so check the current wording of the Code and your credit reporter's listing rules rather than relying on an internal manual written years ago.

Two habits keep teams out of trouble. Send the required notice to the last address you have verified, not the last address you were given. Keep evidence of the notice, the address it went to, and the date. When a listing is later challenged, that evidence is the whole argument. A large share of listing disputes turn on nothing more than whether the notice reached a current address.

Repayment arrangements and hardship

Where a debtor enters an arrangement, or raises hardship, the file position and your collection posture both change. Make sure the arrangement is recorded against the account and that any reporting reflects it. A default listing that continues to say something no longer true is an accuracy problem, not merely a courtesy issue.

Recording purpose at the point of enquiry

The Code assumes that access can be accounted for. Credit reporters log subscriber access, and individuals may ask for their access history. If your own systems cannot show why a particular enquiry was made, you are relying on the credit reporter's log to describe your conduct without your explanation attached to it.

This is why intelID requires an authorised-purpose declaration before every search and stores it with the query, the user and the result. For collections, a good declaration names the account, its status and the step being taken — for example, "locating current address of the named account holder, account 55210, 92 days overdue, to issue a pre-listing notice". Our article on authorised purpose goes into the wording in more detail.

Building the controls into the team

• Restrict credit access by role. Not every collector needs it, and role-based access control is easier to defend than a shared login.
• Require two corroborating identifiers before contacting anyone about a debt. Address plus date of birth, or address plus a second independent record.
• Separate tracing from reporting. Finding a debtor and listing a default are different decisions with different tests.
• Sample and review. Pull a set of enquiries each month and check the declared purpose against the account state.
• Set retention. Delete trace material once the account is resolved and the retention period has run.

Where the platform helps

intelID consolidates licensed credit, company, property, PPSR and insolvency sources into a single search with role-based access and a complete audit log. The collections-specific workflow is set out on our credit and collections page, the sources on the data sources page, and our obligations on the compliance page. To have accounts issued for your team, request access.

This article is general information about a regulatory regime, not legal advice on your situation. Where a listing or a dispute carries real consequences, take advice.