Under consumer-driven banking, a bank's data errors leave with the customer

For most of my career, a data error in a bank had a limited audience. A mistyped employer code, a transaction description that made no sense or a joint account recorded as individual would distort our own reports and, occasionally, one of our own decisions. We found the error, corrected it and, if it mattered, told the customer. Consumer-driven banking changes that. Under the federal framework, which the Financial Consumer Agency of Canada will oversee, customers will be able to direct their bank to share their data with accredited participants: another lender, a budgeting service, an accounting platform for a small business. My position is that once this happens, our data errors stop being internal. They become inputs to other institutions' decisions about our customers, made where we cannot see them and cannot correct them. Banks should prepare by fixing and measuring the shared fields first, publishing what they find and giving customers a way to correct what travels in their name.

What will actually be shared

The early Canadian discussion of consumer-driven banking has concerned accreditation, liability, security and the technical standard for the connection. Those questions matter, and the framework addresses them. Far less has been said about content. When a customer asks us to share their account with a lender assessing a loan, that lender will read balances, transaction history and the descriptions and categories attached to each transaction. It will draw conclusions about income, regular commitments and spending, and some of those conclusions will be automated.

In 2025 my office reviewed the fields most likely to be shared from Aubreuil's chequing, savings and credit card accounts. The results were tolerable by the standards of internal use and sobering by the standards of a stranger's decision. About 6% of recurring payroll deposits carried a description that did not identify the employer. Pre-authorised debits from a single creditor appeared under as many as fourteen descriptions. Our transaction categories, built for our own budgeting feature in 2021, placed some rent payments under transfers and some tuition under retail. Joint accounts opened before 2012 recorded the second holder inconsistently. An analyst inside our bank knows these quirks and works around them. A lender receiving the data through a connection will not.

There is also a language dimension. Merchant and payroll descriptions arrive in English, in French and sometimes in a truncated mixture of both. Our categoriser performed noticeably worse on French descriptions, because most of its training examples were English. A budgeting service relying on our categories would therefore see a francophone customer's spending less accurately than an anglophone's. In a bank where four customers in ten prefer French, that is not a hypothetical concern.

Ownership matters as much as content. When two people hold an account jointly, the transactions of each travel with any data the account shares, and a stranger reading the list cannot tell whose spending it describes. Accounts operated under a power of attorney, or belonging to an estate, raise the same question more sharply. Before any of our data leaves the bank at a customer's request, I want our records to state correctly who holds each account and in what capacity, because that is the first thing a receiving institution will assume it knows.

A quality standard the customer can see

I think a bank should treat the data it shares under the framework as a product with a stated quality standard. For each shared field, the bank should know and publish, in plain terms, how complete the field is, how its categories are assigned and how often they are corrected. It should test each field by language, account age and product, because defects are concentrated rather than evenly spread. And it should give customers a simple way to see what was shared and to ask for a description or category that misrepresents them to be corrected, with the correction travelling onwards the next time their data is shared.

Some colleagues argue that publishing quality measures invites liability and helps competitors. I take both concerns seriously. Our lawyers will need to frame any disclosure carefully, and other banks will learn something about our data. But the alternative is that customers, and the institutions they choose, discover our errors through decisions we never see. If a customer is declined for a loan elsewhere because our records made a steady income look irregular, the fact that the decline happened at another institution will not make that customer think better of us.

We began with three fields: payroll identification, recurring-payment grouping and category. Since mid-2025 we have reduced unidentified payroll descriptions from about 6% to 2.4% and retrained the categoriser on 180,000 French-language examples labelled by our own staff. The accuracy gap between French and English descriptions has narrowed by about two-thirds. The work cost about C$2.8 million in 2025, money that came from analytics projects our marketing team had expected to receive.

Not a compliance interface

The risk I see in many banks' preparations, including at times our own, is that consumer-driven banking becomes a technology project: build the connection to the standard, pass accreditation, meet the date. That framing places the work with the people who build connections and measures success by whether data flows rather than whether it is right. It also invites a minimal reading of what must be shared, which may satisfy the rule and still fail the customer.

I would frame it differently for a board. For the first time, the framework will make the quality of a bank's customer data visible to customers and to institutions they trust, at a scale the bank does not control. That is a reason to fix defects tolerated for years because only the bank itself was affected. It is also an opportunity. A bank whose shared data is reliably accurate, in both languages, makes it easier for its customers to borrow, budget and run a small business wherever they choose, and a customer who finds that easier has one less reason to leave.

The questions I would ask a bank's board are short. Which fields will leave the bank when a customer asks, and who owns each one? How accurate is each field when measured the way a stranger would use it, and does that measure differ between groups of customers? And when a customer tells us that what we shared about them was wrong, what happens next, and how quickly?