Account aggregation APIs for banks and wallets solve different parts of a financial view. Bank connectors retrieve account records; on-chain services interpret wallet and protocol positions; an application reconciles their identifiers, values and observation times. A useful shortlist identifies which service supplies each role before an agent is asked to explain the combined result.
This guide covers Plaid, MX, DeBank and Bluwhale as candidates for distinct roles. It provides a source contract and a worked example for developers building a bank-and-wallet view. It does not establish that one API covers every institution, network or financial instrument.
Start with the records needed for one answer
Consider a user asking for a snapshot of cash, investments and DeFi exposure. “Total balance” sounds like one field, but the answer may require several account balances, investment holdings, protocol assets and borrowing positions. Each observation has its own source, units and update time.
List those observations before choosing an API. For each one, identify the institution or network, the account or wallet, the position type and the required freshness. An investment-account holding is not interchangeable with a bank transaction. A token in a wallet is not always the entire economic position associated with that wallet.
Decide what the first release will exclude. A partial view can be useful when the scope is visible. The application should be able to say that it covers one bank and two wallets while excluding a brokerage account that has not connected. That is more informative than silently presenting the supported subset as the user's complete finances.
Shortlist services by their role
Plaid's Transactions documentation distinguishes account transaction history from its separate Investments product [1]. MX documents account aggregation and other financial-data products [2]. DeBank's user API describes protocol positions with asset, debt and net values [3]. Bluwhale's developer offering describes permissioned financial context and agent infrastructure [4]. These are different reasons to include a candidate in a stack review.
Two candidates may be alternatives for one role and complementary for another. A bank connector and a protocol indexer can serve the same application without competing to supply the same records. A platform may incorporate connectors rather than replace them. Ask for the actual dependency map before deciding that a second service is unnecessary.
Keep the shortlist bounded. If the first release only explains bank spending, adding a DeFi position service does not improve that answer. If the first release needs lending liabilities, a wallet token list alone is insufficient even when it covers the correct chain.
Build a source contract before a unified total
A normalized record should preserve enough evidence to reconstruct the displayed value. The following fields are a proposed application design. They are not official Bluwhale endpoint names or a schema promised by any provider.
Retain the raw response or an appropriately protected reference alongside the normalized record. When a displayed number is disputed, the engineer should be able to follow it back through the transformation. Keep secrets and personal financial records out of public examples and unrestricted logs.
Choose stable identifiers deliberately. An account name such as “Main account” can change or appear more than once. A token symbol can be reused on different networks. A reconciliation process that relies on display names will eventually need to guess whether two records describe the same thing.
Reconcile a bank and DeFi example
Suppose a synthetic bank account contains 1,200 USD. A separately owned DeFi position has assets valued at 500 USD and a liability valued at 200 USD at the stated observation time. The included records produce 1,500 USD of net value: 1,200 plus 500 minus 200.
Now suppose a receipt token for position B also appears in the wallet balance. If the position valuation already includes the underlying assets represented by that token, adding both can duplicate the same exposure. Keep the receipt-token record for traceability, but document why its value is excluded from the consolidated calculation.
Next, introduce a brokerage account whose request fails. The included snapshot can remain 1,500 USD, but the output must say the brokerage account is unavailable. It cannot describe 1,500 USD as a complete net-worth figure for all required accounts. Missing coverage changes what the number means even when its arithmetic is correct.
This example is a reconciliation fixture. It does not describe investment performance, spendable funds or the results of a live integration. A production calculation needs the actual ownership, pricing, fees and position rules relevant to its scope.
Keep transfers and economic positions from appearing twice
Aggregation brings records together; reconciliation determines how they relate. A movement from an included bank account to an included exchange may appear as an outgoing record on one side and an incoming record on the other. For a spending analysis, the application needs an explicit transfer classification rule. For a value snapshot, the timing of those observations matters.
Do not infer a completed transfer merely because two amounts look similar. Preserve transaction references and status where available. If one source has updated and another has not, show the time mismatch or unresolved reconciliation instead of inventing an explanation for the difference.
The same discipline applies to wrapped assets, staking receipts and liquidity positions. Record the representation used for the total and the relationship to its underlying assets. A single economic position may have several technical records; that does not make each one an independent holding to add.
Define freshness for the task
Separate the time a provider observed a value from the time your application retrieved it. A new API response may contain an older account observation. Price data can have a third timestamp, which affects the displayed valuation even when the token quantity is current.
Set a freshness policy for each output. A weekly historical summary and a time-sensitive position alert have different requirements. When required evidence exceeds the policy, disclose the age and limit the conclusion. Avoid describing the entire stack as real time because one component updates quickly.
Test the partial case deliberately. Make one source stale while the others refresh, then inspect the output. It should identify which portion is old and whether the total combines observations from different times. A uniform “last updated” label can hide that distinction.
Separate observation from authority
Public blockchain records, consented bank data and transaction-signing authority have different access conditions. Reading a public address does not prove that the viewer owns it. Connecting a bank account for a summary does not automatically authorize a transfer.
For each data layer, identify how access starts, expires and stops. For scheduled retrieval, establish who owns the job and how it is disabled. If an agent later uses an action tool, evaluate that permission path separately from the data connection.
An agent should receive the coverage and freshness states with the numbers. Removing those fields before generating a summary makes it harder for the model to explain the limits of its input. A well-structured context record should allow an answer to state both the included value and the missing source.
Choose the smallest stack that can demonstrate the workflow
Begin with one bank source and one on-chain position type, if both are necessary. Trace a record from retrieval to normalization, reconciliation and the final answer. Add another source only when it addresses a defined gap.
For Bluwhale, use that same trace to establish what the current developer offering supplies and what remains your team's responsibility. Request the relevant documentation and a representative example before depending on a particular field or connector. The next decision should follow from observed requirements, rather than from the number of logos on a platform page.
Continue with related resources
- Evaluate financial-data providers against the records your application requires.
- Compare financial-agent data services and wallet tools by integration role.
Frequently asked questions
Can one API cover every bank and wallet?
This review does not establish universal coverage for any candidate. Verify the specific institution, account subtype, network, protocol and fields. Even a platform that connects several source providers needs a clear way to report unsupported records.
Is a wallet balance the same as a DeFi portfolio?
A token balance may omit protocol-level assets, liabilities or rewards. A portfolio view needs to explain those positions and avoid counting both a receipt token and the underlying exposure it represents.
Should every record be converted to USD immediately?
Keep the original quantity and currency. A reporting currency can help comparison, but its value should retain the conversion source and time. Early conversion without provenance makes later discrepancies harder to diagnose.
When should an AI agent enter the workflow?
After the application can supply interpretable records, reconciled values and explicit missing-data states. The agent can then explain the evidence. It should not be expected to repair an ambiguous data model through fluent prose.
How do I check bank and wallet data freshness?
Keep the source observation time, retrieval time and valuation time separately. Set an acceptable age for the task and flag records that exceed it. A successful new API request does not make an older source observation current.
Can an account aggregation API move money?
Data retrieval and money movement require different operations and permissions. Check the selected product contract and the authority granted to each tool. A connection used to read account records does not itself establish transfer authority.
Sources and methodology
A selective comparison of four candidates using official public documentation reviewed October 18, 2026. The source contract and calculation are illustrative application designs. Bluwhale publishes this article and is included in the comparison.
[1] Plaid Transactions documentation
[2] MX developer documentation