Alexandra BrooksChief Product Officer · Essays & perspective
← All essays

Data access and consent5 min read

Every app that reads a member's account belongs on one screen

Credit unions have let members hand their passwords to budgeting and payment apps for years without showing them who holds access. A member should see every connection in her own credit union's app and end it there, and credit unions should stop accepting stored-password access whatever the federal rule's timetable.

My position is simple to state and expensive to carry out. A credit union should show each member, inside its own app, every third party that can read her account: the app she connected, the company that carries the data for it, what it can see, when it last looked and a control to end the connection. It should also stop accepting the oldest form of access, in which an app signs in with the member's own username and password, as soon as each data company offers a safer route. Neither step should wait for federal rules on consumer data access to settle.

I hold this view because of what I found at Lanternfield, the credit union service organisation where I lead product. We run digital banking for 74 credit unions. In 2024, 29% of all sign-ins to our platform were not members at all. They were automated sessions run by data aggregators, the companies that collect account information on behalf of budgeting tools, payment apps, lenders and tax software, using credentials members had typed into those apps. About 1.1 million members had given their credit union password to at least one third party. Almost none of them could have told you which.

What a stored password tells a credit union

A sign-in with a stored password tells a credit union almost nothing it needs to know. It cannot distinguish the member from the app, the app from the aggregator behind it, or any of them from a criminal testing stolen credentials. Our fraud team had learnt to recognise the aggregators' traffic by its addresses and timing, and attackers had learnt to imitate it. When a member asked her credit union to cut off an app she no longer trusted, the only reliable advice was to change her password, which broke every other connection she wanted to keep.

The arrangement also gives the third party far more than it needs. An app built to show spending categories received, through the member's password, the same access the member had: statements, transfer screens and the ability to change contact details, even if the aggregator only ever read balances. We were relying on companies we had no agreement with to choose restraint.

Token connections fix most of this. The member signs in on the credit union's own screen and chooses what the app may see, and the credit union issues a credential that can read only that data and can be withdrawn without touching the password. The technology has existed for years, and the larger aggregators support it. What credit unions have lacked is the decision to require it and the product work that makes it understandable to members.

The screen we built and what members did with it

We built a page in the shared app called Connected apps. It lists every active connection under the name of the app the member actually used, with the data company named underneath, the categories of data shared, the date of the last access and a button to disconnect. We released it in April 2025 and set March 2026 as the date from which we would refuse password sign-ins from any aggregator that offered a token route.

What members did surprised our credit unions more than it surprised me. By June 2026 they had ended 186,000 connections, most of them to apps they told us, in a one-question survey, that they had stopped using, and a meaningful minority to apps they did not recognise. Nobody had asked them before. Automated sign-in volume fell 81% after the cutover, and confirmed account takeovers across our client credit unions fell from 212 in 2024 to 64 in the twelve months to June 2026. I would not attribute all of that fall to the change, because our fraud controls improved in the same period, but attackers lost the cover of a crowd.

We made mistakes. In the first version the list showed the data company's name rather than the app's, so members saw names they had never heard of and disconnected apps they still wanted. In the month after the cutover, credit union contact centres took 9,400 calls about broken connections, because we had given aggregators nine months' notice and the credit unions' own staff only six weeks. Both were failures of our product work, not of our members.

Why waiting for the rule is the wrong default

The federal rule on consumer-permissioned data access has been written, challenged and reopened, and I do not know what its final form or timetable will be. Several credit union leaders argued that we should do nothing until it settled, and our chief technology officer made the strongest version of that case: why build twice? I understood the argument and disagreed with it.

A rule of this kind, whatever form it finally takes, governs what institutions must allow. It does not decide what a member is able to see. A credit union that waits is choosing, for every month of delay, to keep accepting sign-ins it cannot attribute and to leave its members unable to answer a basic question about their own accounts. Credit unions also carry this risk through partners in a way they did not ten years ago. Federal banking supervisors have spent the past few years acting against banks whose fintech partnerships outran their oversight, and the lesson for a credit union does not depend on any rule: if your members' data leaves through a door you do not control, you own the consequences without owning the door.

There are fair objections. A smaller credit union's members may depend on an app whose aggregator is slow to offer tokens, and a hard cutover can cut them off. We handled that by setting the date per aggregator rather than per app and by keeping a narrow exception route. Some fintech firms argue that a credit union controlling the consent screen will use it to discourage competitors. That risk is real, so our page uses neutral language, carries no warnings about any named app and looks the same for every connection. A credit union that wants to steer members away from a rival should do it in the open, not on a permissions page.

I would ask any credit union or bank board to request one number and one demonstration. The number is the share of sign-ins to its digital banking that come from third parties using members' passwords. The demonstration is a member of staff, using her own account, showing the board where she would go to see which apps can read it and how she would end one. If either answer is uncomfortable, the rule is not the reason to act. The members are.