One of the biggest remaining challenges in the Chase Authorized User Reimburser is getting data into it.
The current process still requires the primary account holder to sign into Chase, export recent activity, and copy the additional transaction information used to identify which authorized user made each purchase.
Plaid looked like a promising way to remove that work.
The goal was straightforward: connect Chase once, retrieve transactions automatically, and eliminate the recurring export and import process. That would save time, simplify the weekly workflow, and reduce opportunities for mistakes.
So we tested it with real Chase data.
The good news was that Plaid worked. It connected to the Chase account through OAuth and returned hundreds of real transactions with the kind of ledger data the application needs: amounts, dates, merchants, pending and posted status, and stable transaction identifiers.
The problem was more specific.
It couldn’t tell us which cardholder made the purchase.
That’s the information that makes this application different from a basic transaction ledger.
Plaid does provide an account_owner field for certain sub-account situations,
including cases where one account has multiple cards with different
cardholders. But Plaid’s own documentation says the field is not typically
populated and that the information available varies by financial institution.
In our Chase test, that attribution wasn’t there. The authorized-user names weren’t available in the transaction data, and we couldn’t find another stable card or sub-account identifier that could reliably tell the application which person made each purchase. That matched the uncertainty we had identified before doing the test.
We wondered whether some of this might simply reflect deliberate limits on the financial data exchanged between institutions and applications. There are plenty of security, privacy, and compliance reasons to be careful with financial data. But we found no evidence that PCI requirements, privacy rules, or another specific regulation are the reason Chase doesn’t provide this particular information, so we won’t pretend to know.
What we can confirm is narrower: Plaid documents account_owner as institution-dependent and provides examples at other institutions where only limited card-level information is available.
That was enough to make the product decision fairly straightforward.
Useful automation has to remove useful work.
Plaid could automate transaction retrieval. That’s a real benefit.
But the primary account holder would still need to visit Chase to obtain the authorized-user information required for reimbursement assignment. The application’s current workflow would therefore become partly automated rather than automatic.
That benefit has to be weighed against what Plaid would add: another integration, provider cost as usage grows, access-token handling, additional privacy and security considerations, and more application complexity.
The project decision was to retain the existing Chase import workflow and put the near-term effort into making that process easier instead.
That doesn’t change the usefulness of the application. It simply means an enhancement we hoped could eliminate most of the manual data collection isn’t worthwhile yet.
For now, the better path is to make the existing process clearer, add stronger validation, and reduce opportunities for mistakes.
Plaid isn’t ruled out forever. We’ve left the question in the backlog. If Chase or another provider eventually exposes reliable transaction-level authorized-user attribution, the decision is worth revisiting.
Until then, the benefits of integrating Plaid do not outweigh the additional weight, complexity, and cost it would add to the application.