IBM has featured wealthAPI in its global product blog series “Beyond the Blueprints.” The post, which I co-authored with Chad Jennings from the IBM team, offers the first detailed look at the data architecture we have built at wealthAPI to turn fragmented banking and brokerage data into real-time, AI-driven financial insights.

Why data pipelines in wealth management are particularly demanding

Financial institutions and fintechs that want to give their users a coherent view of net worth, positions and performance in real time quickly run into a structural problem: data arrives from dozens of sources — banks, brokers, crypto wallets — with inconsistent standardization, varying latency and highly unpredictable volume. Traditional advisory processes that rely on manual data reconciliation and periodic reviews do not scale in this environment.

On top of that come regulatory requirements that are non-negotiable in financial services: DORA compliance, BaFin regulation, EU data residency obligations. These constraints need to be built into the architecture from the start — not retrofitted.

The architecture: separating workloads by design

The core of our solution is a clear separation of data layers by access pattern, latency and structure:

• Event-driven ingestion: Incoming data flows through Google Pub/Sub as a message-queue layer. This decouples producers from downstream services and provides elastic buffering — multiple services can consume the same event stream without being tightly coupled.
• Unstructured analytics data: Google Cloud BigQuery serves as the primary store for high-volume, often unstructured operational data: usage logs, error tracking, data quality tracking and bank-response tracking. Schema-free ad hoc querying across large datasets is what this layer requires — BigQuery is the right tool for the job.
• Structured high-performance workloads: For structured data that demands high read and write throughput, we use IBM watsonx.data. The routing rule is pragmatic: if the data fits well in SQL, it stays in SQL. If it is unstructured, multi-terabyte and does not require high read performance, BigQuery works well. If it is structured and requires excellent performance at scale, watsonx.data is our choice.
• AI-ready enrichment: A core differentiator in the architecture is embedding generation and similarity search in production. Data arrives through the event stream, a model generates embeddings based on the use case, those embeddings are stored in watsonx.data and the platform performs similarity searches — for example to make a wide variety of investment assets comparable across sources, from stock quotations and reference data to ETFs.

The results

This architecture delivers measurable outcomes: up to 80% improvement in response times for end users, reduced write times and better collision handling under load. The more important point, however, is not any single metric but the underlying principle: a stable, regulatory-compliant data foundation that allows teams to add new AI models, new partner integrations and new user-facing features without rebuilding the core each time.

Anyone building financial platforms for B2B partners and their end users needs exactly this property: the ability to move fast without sacrificing stability.

Read more

The full article is available on the IBM Product Blog: Building AI-ready financial intelligence pipelines with IBM watsonx.data and Google Cloud BigQuery