Connect bank and wallet data to an AI agent by establishing account permission, a consistent record model and a traceable path from each source to the agent’s answer. The result is financial context that can support useful summaries, account explanations and monitoring across the sources a user chooses.
Bluwhale’s Financial Data API brings permissioned financial context into the developer journey. Its Account Aggregation API page describes the account-connection layer. Use the two roles together when planning your integration: connect the relevant sources, then prepare the records your agent needs to answer a defined question.
1. Set the account scope before connecting
Start with the user’s task. A weekly balance summary may need selected bank balances and wallet positions. A cash-flow explanation needs a reporting period and transaction records. A portfolio view needs holdings and valuations. This task-first approach gives the permission journey a clear purpose and helps the user select the right accounts.
Create an account inventory with the institution or network, account type, requested records and the user’s relationship to that account. Record the reporting boundary separately from the connection itself. A joint bank account, a personal wallet and a business treasury wallet can belong to different reporting views even when one user can access all three.
Use a wallet address as an identifier within a specific network. Keep the user’s assertion of ownership or control as a separate field in your application. Likewise, keep bank account ownership details separate from successful account linking. This makes the agent’s context reflect the financial scope the user has actually selected.
2. Make the permission journey clear
Before the connection step, explain which records the feature uses and the outcome they enable. Offer account selection where the integration supports it, show the connected sources after setup, and provide a clear path to manage access. The user should be able to connect a source with a concrete understanding of the report or feature it supports.
Plaid’s Link documentation offers a useful example of an account-linking flow organized around institution login, account selection and returning to the application. The transferable practice is a purposeful connection journey with visible account scope. Build the flow around the capabilities of your selected integration.
Keep authorization records in the application layer. Associate each connection with the authenticated user and permitted data scope, and check current access before each run. For a reporting feature, configure data-reading permissions. Treat any future payment, trade or signing workflow as its own product capability with its own authorization.
3. Map bank and wallet records into one model
Normalize dates into a consistent time zone while retaining the source’s original timestamps. Preserve native currencies and token quantities alongside converted reporting values. A refreshed connection time, an account observation time and a market price time describe different events; keeping them distinct makes the answer easier to explain.
For token records, store the network and contract identifier where applicable. For transactions, use stable source references to recognize records already processed. These identifiers help your application maintain a consistent history as providers refresh or correct records.
4. Reconcile the financial story
Illustrative transfer: the user moves $300 from a connected bank account to a connected exchange account. The bank records an outgoing payment and the exchange records an incoming deposit. When those entries represent the same transfer within the selected reporting scope, group them as an internal movement. They explain a change in account location while leaving the combined total unchanged, assuming no fee or price movement.
Match candidate transfers using source references where available, then compare amounts, currencies, destinations and timing. Preserve any fee separately. Give ambiguous matches a review state so the application can request a classification instead of silently assigning one.
Use the same principle for portfolio positions. If a wallet sends tokens into a DeFi position, represent the economic exposure consistently across the wallet and protocol views. Keep the position’s components available for drill-down, and define which representation contributes to the combined total.
5. Prepare the agent’s context and output
Supply a compact, structured context package: selected account list, reporting period, normalized values, reconciled movements and source references. Include the account and price dates needed to interpret those values. Your application can calculate totals and classifications before the model turns them into a clear explanation.
- Retrieve: collect authorized records for the selected task.
- Normalize: map identifiers, dates, amounts and currencies.
- Reconcile: group transfers and resolve duplicate records.
- Calculate: produce totals and changes with a stated method.
- Explain: generate the answer with a path back to the source evidence.
Keep the model’s instructions focused on the reporting task. Source descriptions and transaction memos are input data; account access remains governed by your application’s policy. The OpenID FAPI specifications are a reference for teams designing protected API access, alongside the documentation of their actual integration.
6. Start your connected workflow with Bluwhale
Bring a short integration brief to Bluwhale’s developer platform: the user task, account sources, required fields, reporting cadence and an example answer. This lets your team map the first release to the financial context it needs. Continue with the Financial Data API for the data layer and the financial summary agent guide for the reporting workflow.
Test the complete journey using representative records: initial linking, a refresh, an internal transfer, a corrected transaction and a change in permission. Save the expected result for each case so the workflow can be checked again as the integration evolves.
Common questions
What is the difference between account aggregation and agent context?
Account aggregation connects and retrieves the relevant account records. Agent context organizes those records around a task, including the reporting scope, dates, calculated results and source references needed for an explanation.
Does reading wallet data require transaction authority?
A tracking or summary workflow can use data-reading access. Sending funds, placing an order or signing a transaction requires a separately defined action workflow and the corresponding permission.
How should the agent describe a transfer between connected accounts?
When both sides belong to the reporting scope, describe it as an internal transfer. Account-level balances change; the combined total reflects any associated fees or valuation changes.
Sources and further reading
Reviewed October 11, 2026.