Account Aggregators: Which Bank Data Gets Shared?

Account Aggregators And Data

Account aggregators are services that connect to your financial accounts and then share selected data with another party, such as a budgeting app, lender, or insurer. The key point is that data sharing happens through permissions you grant, not by copying your entire bank history into a new system.

In practice, you usually link an account using a login flow or an API connection, then choose what the receiving service can access. Some aggregators focus on “read-only” transaction and balance data, while others also support account metadata like account type or institution name. A budgeting app might request transactions for the last 90 days, while a credit application might request longer history or specific fields like payment amounts.

What gets shared depends on the aggregator’s connectors, the receiving service’s data needs, and the legal framework in your jurisdiction. Even within the same country, providers may expose different fields through their APIs, and some fields may be masked or normalized. I’ve seen permission screens that show “transactions” but hide whether merchants are included, and that detail changes how useful the data becomes.

Common Data Sharing Mistakes

People often assume an aggregator shares “everything the bank has,” then get surprised when a feature fails because a field is missing. The opposite also happens: someone grants broad access because the app’s wording sounds harmless, then later realizes the receiving service can see more than they expected.

A frequent misunderstanding involves the difference between account-level access and transaction-level access. Account-level data might include balances, account status, and account identifiers, while transaction-level data includes dates, amounts, descriptions, and sometimes merchant names. If a lender only needs balance snapshots, it may request fewer transaction fields, but the aggregator still has to map what the bank provides into a consistent schema.

Another pain point is assuming “read-only” means “risk-free.” Read-only access can still expose sensitive information such as recurring payments, employer-related deposits, or travel spending patterns. Fraud risk also exists if you reuse passwords across services or if a connector is misconfigured, which is why permission reviews matter even when the aggregator claims limited scope.

Supporting technologies shape what’s available. Many aggregators rely on bank-provided APIs, screen-scraping connectors, or standardized data-sharing frameworks. The available fields differ across these methods, and the aggregator’s normalization layer can change formats like timestamps, currency codes, or merchant descriptors. In one connector I reviewed (version noted in the app’s help page as “v2.3.1”), transaction descriptions were truncated to a fixed length, which made merchant matching less accurate.

What To Check Before Linking

Review Permission Scopes

Start with the permission screen and look for categories, not marketing labels. Common categories include balances, account details, and transaction history. If the UI shows a date range, treat it as a hard boundary and confirm whether the receiving service can request extensions later.

When possible, choose the narrowest scope that still supports your goal. For budgeting, a shorter transaction window often works at first, then you can expand if you need seasonality. For credit underwriting, the lender may require a longer window, and the aggregator may need to fetch more records to compute income patterns.

Also check whether the receiving service can access “merchant” or “counterparty” fields. Some aggregators provide merchant names only when the bank sends them, and others infer categories from descriptions, which can affect accuracy.

Inspect Data Fields And Formats

Look for field-level details in the aggregator’s documentation or the receiving app’s privacy page. Transaction fields can include posting date, transaction date, amount, currency, and a free-text description. Some systems include category labels, while others provide only raw descriptions that you must categorize yourself.

Format differences matter. Timestamps may be in local time or UTC, and “pending” transactions may appear separately from “posted” transactions. If you’re reconciling balances, you need to know which status the aggregator includes. I’ve seen apps that treat pending transactions as final, which can make your available balance look wrong for a few days.

If the aggregator masks account numbers, confirm whether it keeps the last 4 digits or a hashed identifier. That affects how you match transactions to the right account when you link multiple accounts.

Confirm Retention And Sharing Limits

Permissions control access, but retention rules control what happens after access. Check whether the receiving service stores raw transactions, stores only derived summaries, or deletes data after a decision is made. If the privacy policy is vague, request clarity through the app’s support channel.

Retention can also be tied to audit needs. Lenders and insurers may keep records longer for compliance, while budgeting apps may keep data for user history. The aggregator itself may cache data temporarily to reduce repeated fetches, which can still be sensitive.

Ask how revocation works. Some services stop future pulls immediately, but previously imported data may remain in your account until you delete it manually.

Use Safer Linking Practices

Prefer connectors that use bank APIs or standardized consent flows rather than password-based screen scraping. API-based flows typically reduce the chance that your bank credentials are exposed to third parties, though the exact security model varies by provider.

Use unique passwords for the aggregator and the receiving app, and enable multi-factor authentication where available. If the aggregator offers a “disconnect” option, test it by checking whether the receiving app stops updating after you revoke access.

Keep an eye on the app version and connector behavior. In one case, an app update changed how it displayed the consent date range, and users who didn’t re-check permissions ended up with a longer history than intended. That kind of mismatch is easy to miss when the UI doesn’t highlight changes.

Educational Case Examples

Budgeting App With Short History

A user links a checking account to a budgeting app and grants access to “transactions” for the last 90 days. The app imports posted transactions with amounts and descriptions, but merchant names are missing because the bank connector only provides generic text. The user still gets accurate totals by category after manual tagging, but recurring bill detection takes longer because the app can’t match merchants reliably.

After reviewing the permission screen, the user expands access to 180 days. The app now includes more complete descriptions, and the recurring payment feature starts working because it has enough history to infer patterns. The user revokes access after setting up categories, then keeps using the imported data without further updates.

Loan Application With Balance Snapshots

A borrower applies for a small loan and grants access to account details and balance history for a defined period. The lender’s workflow uses balance snapshots to estimate income stability, so it requests fewer transaction fields than a budgeting app would. The borrower notices that the consent screen lists balances and “account status,” but it does not list merchant details.

After approval, the borrower checks the receiving app’s settings and finds that imported balances remain visible for reporting, while new pulls stop after consent revocation. The borrower deletes the imported transaction view in the app because the lender’s decision is already complete, reducing ongoing exposure.

Data Sharing Checklist

Use this checklist to decide whether the shared data matches your risk tolerance and your goal.

1. Write down your goal in one line: budgeting, underwriting, reconciliation, or fraud monitoring.
2. Match the goal to the minimum permission categories that support it.
3. Confirm the date range and whether pending transactions are included.
4. Check whether merchant/counterparty fields are present, because that affects accuracy.
5. Look for retention language: how long the receiving service keeps raw data and derived summaries.
6. Test revocation: disconnect and verify the receiving app stops updating.

Common Mistakes To Avoid

Granting access without reading the consent details is the most common mistake, but the second mistake is assuming the consent screen matches what the app actually uses. Some apps request broad scopes and then only use a subset, while others request narrow scopes but later ask for more when a feature is enabled.

Another issue is ignoring data quality constraints. If the aggregator normalizes descriptions, merchant matching can fail, and users may misinterpret missing transactions as “no activity.” That leads to incorrect budgeting decisions and unnecessary support tickets.

People also forget that revocation may not delete already imported data. If you want data removal, you need to check the receiving app’s deletion controls, not just the aggregator connection status.

Finally, users sometimes link accounts during a trial period and then forget to review permissions after the trial ends. A small UI change can keep consent active longer than expected, and the app may start pulling additional accounts you didn’t intend to share.

FAQ

Which Bank Data Is Shared Most Often?

Most aggregators share balances and transaction records, usually including posting date, amount, and a description field. Some also share account metadata like account type and masked identifiers, while merchant names and categories depend on what the bank provides and how the aggregator normalizes it.

Can I Limit Access To Only Transactions?

Many consent flows let you choose categories such as balances, transactions, and account details. If the receiving service needs balance snapshots for underwriting, it may request balances even when you select transactions, so check the exact scopes shown during consent.

Does Revoking Consent Delete Previously Imported Data?

Revoking typically stops future data pulls, but it often does not automatically delete data already stored by the receiving service. Deletion depends on the receiving app’s settings and retention policy, so look for a “delete data” or “manage data” option.

Why Do Merchant Names Sometimes Disappear?

Merchant names depend on the bank’s data feed and the connector’s mapping rules. Some connectors provide only generic descriptions, and the aggregator may truncate text or separate fields, which can reduce merchant matching accuracy.

Is Read-Only Access Still Sensitive?

Yes. Even read-only transaction data can reveal income sources, recurring bills, and spending patterns. The privacy risk comes from what the receiving service stores and how it uses the data, not from whether the aggregator can write back to the bank.

Author's Insight

Account aggregators typically share a limited set of data categories chosen during consent, but the exact fields vary by connector and by the receiving service’s requirements. The most reliable way to predict what you’ll get is to inspect the consent scopes, date ranges, and any field-level descriptions in the app’s documentation or privacy materials.

Data quality also matters: normalization can change timestamps, truncate descriptions, or omit merchant fields, which affects budgeting accuracy and reconciliation. If you need dependable results, test with a small date range first, then expand only if the data supports your use case.

Consent revocation usually stops future access, yet it may not remove previously imported data. Checking deletion controls and retention language reduces the gap between “disconnected” and “gone.”

Key Takeaways

• Consent screens usually control categories like balances, transactions, and account details, but the exact fields depend on the connector and the receiving service.
• Merchant names, pending transactions, and timestamp formats vary, so data quality can limit what you can do with the imported records.
• Revocation often stops future pulls; deletion of already imported data depends on the receiving app’s settings and retention policy.
• Use the smallest date range and narrowest scope that supports your goal, then expand only when the data proves usable.