Someone has savings in one bank, a current account in another and an investment account elsewhere. A financial-planning app offers to display them together. The dashboard looks useful until one balance is stale, a consent expires or the person withdraws permission and mistakenly believes every previously retrieved copy of their data has vanished. Open banking account information services must manage all those events honestly.
These services retrieve or present permitted financial-account information through authorised connections, with the customer’s consent and under the relevant legal framework. They are different from payment-initiation services, which instruct payments, and different again from identity proofing. Their gold standard is a relationship in which the customer understands which information is available, who can use it, how current it is, and what changing consent actually does.
Singapore’s SGFinDex provides a valuable example of consent-driven financial data aggregation. The UK Financial Conduct Authority explains distinct regulated account-information and payment-initiation services within its own framework. The management principles link to eduKate’s Financial Identity Verification, Financial Planning and Gold Standard hub.
How to read an aggregated account dashboard
| Display element | Customer should know | Failure to avoid |
|---|---|---|
| Connected institution | Who supplied each dataset | Unknown source |
| Balance time | When data was last retrieved | Stale figure shown as live |
| Total assets | Currency and account coverage | Mixing liabilities and assets |
| Consent | Receiving party, scope, purpose | Blanket permission |
| Revocation | Which future access stops | Assuming historic copies disappear |
Read the 16 chapters
1. An account summary should identify the real financial data source
A user may see a consolidated number labelled ‘total cash’ while the source accounts have different currencies, update times and ownership structures. A credit-card balance may be a liability rather than an asset; an investment value may be an indicative market estimate. Summing them indiscriminately turns data aggregation into an inaccurate financial statement.
The service should preserve each source institution, product type, balance definition, currency and as-of time. Explain the calculation behind any overall figure. Customers must be able to open a detail view and discover whether a value is live, delayed or estimated, rather than relying on an attractive number whose construction nobody can reproduce.
2. Clarify the role of the data holder and the account-information service
The original bank or institution maintains its own account records. An authorised account-information service retrieves certain permitted information, and a financial-planning application presents or analyses it. These can be separate organisations or parts of one group. A single brand in the interface should not conceal which institution actually supplied a questionable transaction.
Map the participating organisations and permitted uses in the user’s journey. The UK FCA’s consumer explanation distinguishes account information from payment initiation and tells consumers to check relevant authorisation. The regulatory status of one service does not automatically grant authority to perform the other.
3. Consent must describe a purpose, not merely collect a click
A person can agree to retrieve accounts for a financial-planning view without necessarily agreeing to unrelated marketing, broader data sharing or future credit profiling. Presenting every possible permission in one long checkbox risks obscuring the real decision. Customers need to know which accounts, data categories and purpose the permission covers.
Design the consent request at the point of use, with meaningful choices and a clear explanation of the receiving party. SGFinDex’s official site states that participating financial institutions must obtain consent each time their application retrieves data through that service. That specific arrangement must not be misrepresented as the universal rule for every country and API.
4. Distinguish linking an account from refreshing its data
A user may previously have authorised one account connection but not initiated a recent data update. An app may display saved transaction information even after a later refresh fails. Some providers offer real-time-looking interfaces over historical records. A connected account indicator therefore does not prove the data is current.
Show the last successful retrieval separately for each institution and each meaningful dataset. Explain when fresh consent or authentication is required under the actual service. If refresh fails, warn that values are stale rather than silently serving them as current. The customer should not have to guess whether a balance represents today or last month’s planning session.
5. Revocation stops authorised future retrieval under its actual terms
Customers should be able to withdraw consent through a clear route. But revocation of future access and deletion of data already lawfully obtained are different actions, especially where financial institutions have retention obligations. A simplistic ‘erase connection’ button may unintentionally imply that every prior data copy has disappeared.
The SGFinDex FAQ explicitly notes that revoking a data contributor stops future retrieval through SGFinDex but does not automatically delete previously retrieved data held by other participating institutions. An honest service explains the difference, the relevant retention rationale and how the customer may contact each institution for further questions.
6. Keep authentication separate from data-use permission
Signing into an online bank can establish that a person controls the bank account. It does not necessarily authorise an unrelated service to retrieve all information from it. Conversely, a consent confirmation that is not properly bound to an authenticated account can expose another person’s records.
Design and review authorisation flows so that the customer understands which provider requests access, which institution authenticates them, what data is shared and how the result returns safely. Do not ask users to disclose bank passwords to an unfamiliar site when a supported secure consent mechanism exists. Account access and the downstream use of retrieved data need separate controls.
7. Treat stale and partial coverage as decision risks
An aggregation app may have connected three out of five accounts successfully. A customer could then conclude that the household has enough savings for a major commitment based on an incomplete picture. Unconnected accounts are not equal to zero balances, and a provider should never make them disappear merely to improve the appearance of completeness.
Show connected and missing institutions, update status and relevant excluded products. Any total should identify whether it includes just the accounts linked and recently retrieved. The tool can aid decisions but should not claim to deliver a complete financial portrait unless it actually has the information needed to support that claim.
8. Match transactions without erasing their original meanings
Transaction descriptions and categories can differ between institutions. A card refund may appear separately from the purchase. A transfer between a person’s own accounts can be mistaken for both income and spending. An app that charts aggregate expenses without resolving these cases can exaggerate a household’s expenditure.
Preserve source entries and explain categorisation and de-duplication assumptions. A classification model may assist but should allow user correction without altering the bank’s original record. The gold-standard service keeps an audit trail between a planning category and the underlying transaction, so an unexpected number can be investigated.
9. Manage currencies, asset values and liabilities carefully
A salary account in Singapore dollars, an overseas savings account in pounds and a fund holding valued in another currency cannot be added meaningfully without currency conversion. Loans and credit-card amounts may have different accrued charges or statement cut-offs. Even a mathematically correct conversion can mislead if the rates and valuation times differ.
State the conversion basis, source and approximate time of any exchange rate used. Keep positive assets separate from liabilities before calculating a net figure. If investment values are delayed or estimated, label them. The financial planner’s job is to help the user understand uncertainty, not to manufacture a reassuringly precise total.
10. Protect the data in transmission and after receipt
Account data can reveal wages, financial obligations, merchant relationships and sensitive aspects of daily life. Encryption during retrieval is necessary but does not address every risk after a receiving institution stores, analyses or shares the information. Employees, vendors and recovery systems need appropriate controls too.
SGFinDex explains that retrieved financial data is encrypted and decryptable by the financial-planning application the user authorises. A receiving institution should govern retention, access permissions, incident response and onward uses according to applicable law. Review the actual data journey, including backups and analytics, rather than assuming secure transmission makes the entire service private by default.
11. Do not convert a planning permission into unrequested sales pressure
Data aggregation can create insight into a customer’s savings, income or investment holdings. A commercial provider may also sell financial products. That combination can create an incentive to turn a useful planning feature into product recommendations based on information the user did not expect to drive sales.
Disclose the data-use purpose and distinguish general analytics from personal advice or regulated recommendations. Review conflicts and access boundaries before deploying cross-selling features. Under SGFinDex, the user’s selected participating financial institution may use data for specified financial-planning services under its consent terms; a provider should explain actual authorised uses rather than implying data has no commercial consequences.
12. Include accessible ways to connect and disconnect accounts
A customer may have no suitable smartphone, use accessibility software, or struggle with a remote authentication flow. A service that refuses to explain failures or requires repeated biometric attempts can deny legitimate access to helpful financial planning. At the same time, support teams cannot bypass identity and account security informally.
Test connection, refresh and revocation journeys with supported assistive technologies and different devices. Offer an appropriate help channel that explains requirements and lawful alternatives. A valid applicant should know what failed and how to proceed without revealing secrets to an unauthorised support caller.
13. Make incorrect source data and incorrect aggregation different cases
A transaction on the original bank statement may be wrong, or the statement may be correct but the aggregation service duplicated an entry. The person needs a practical path to the right organisation. An app that automatically blames the original bank for its own classification error creates unnecessary delay.
Maintain case evidence showing the source response, transformation and displayed figure at the relevant time. If the issue arose in the aggregation logic, correct it and assess which summaries were affected. If the original record is contested, provide the official route to challenge it with the source institution. A complete handoff matters more than a quick generic reply.
14. A fictional pension-planning snapshot goes out of date
Imagine a mid-career worker using a consent-based planning app to compare savings and debts. The customer had retrieved accounts last month. A large loan payment has since cleared one bank, while an overseas account failed to refresh. The dashboard still announces a precise net worth and makes a savings recommendation using the stale snapshot.
A stronger service warns that the planning picture is incomplete, identifies the last retrieval date for each source and lets the person refresh valid accounts or continue with clear limitations. The fictional case illustrates how truth in data aggregation depends on timestamps and coverage as much as attractive charts.
15. Measure comprehension and correction, not just connected accounts
An operator can celebrate thousands of linked accounts while masking a high rate of stale data and failed consents. Better measures include successful authorised retrieval, freshness by source, mismatched balances, accurate revocation execution, unexplained data-use complaints and time to resolve aggregation errors.
Test the user journey by asking whether someone can identify the recipient, purpose and scope of data sharing without reading a complex technical appendix. Inspect recurring failures by account type and provider. The gold standard is not how much information the system can ingest but whether people can use it reliably and knowingly.
16. The gold standard leaves the customer in control of meaning and access
Open banking can make financial planning easier by allowing authorised data from separate institutions to be presented together. But customers must retain a real understanding of what has been retrieved, where it went and how to limit future use. A service becomes unsafe when it conceals stale figures or treats consent as permanent once clicked.
Gold-standard account information services combine accurate aggregation, secure permissions, honest revocation explanations and effective correction. They make complex financial data more usable while preserving the distinction between a sourced record, an analytical estimate and a new financial decision.
A meaningful consent and data-integrity review
- Can the customer identify the source and last retrieval time of each displayed balance?
- Does consent name the data, purpose and receiving institution?
- Can the user revoke future access, with a truthful explanation of previous copies?
- Are errors in the original institution’s records distinguished from errors in aggregation?
- Are products, currencies and liabilities classified without hiding exclusions?
- Can users connect, seek help and revoke access without insecure workarounds?
Official Singapore and international references
- SGFinDex: Official Portal and FAQs — including consent, encryption, revocation and historical data handling.
- UK Financial Conduct Authority: Account Information and Payment Initiation Services — UK regulatory context.
- MoneySense Singapore: Financial Planning and Consumer Financial Information.
- eduKate: Financial Identity Verification.
- eduKate: Financial Planning.
- eduKate: Gold Standard Sectors and Services Directory.
General service-design education, not a declaration of the requirements applying to a specific account-information provider. SGFinDex and UK account-information services have their own frameworks; consent and retention must follow the actual service and local law.