What happened on this account?
Filter transactions by account and time. Join customer records and aggregate the result.
Query the recordsBanking · Customer and transaction context
Bring account data, transaction relationships and policy search into one database for the applications your banking teams build.
Start with an account, inspect its transfers, and follow the recorded recipient. Your application brings that evidence together for an analyst.
Two transfers resolve to the same recorded counterparty.
Passage: “Check the recipient’s recorded details.”
Policy PL-07 · passage 12Compare the transfer sources with the relevant policy. Record the finding and the next action in the case.
Illustrative account, transfers and policy text. The application retrieves the policy and assembles the case; the relationships do not establish a risk finding.
5 use cases / Banking
Start with the combination that fits your question. These are recommended starting points; the best fit depends on your data and query patterns.
| Use case | Recommended modalities | Why this combination fits |
|---|---|---|
| Account servicing Bring balances, account details and recent activity into a service view. | SQL joins customer and account records, filters recent transactions and calculates the totals the service team needs. | |
| Connected-account investigations Explore transfers between accounts and their recorded counterparties. | SQL narrows activity by amount and time. Graph follows account and counterparty links to reveal the connected records. | |
| Case evidence review Connect an investigation to its correspondence and supporting documents. | SQL selects case records, Graph connects accounts and documents, and FTS finds names, phrases and references within the evidence. | |
| Policy knowledge retrieval Find relevant policy passages for a service or operations question. | FTS matches policy terms; Vector retrieves passages with similar meaning. SQL supplies document versions and business context for the application. | |
| Branch operations reporting Track transaction volumes and service workloads by branch and period. | SQL groups operational records by branch, date and status, with the underlying rows available for drill-down. |
Combine query results in your application using shared record IDs. Keep text indexes and embeddings updated as the source data changes.
Share stable record IDs across your models so the application can resolve each result back to its source.
Filter transactions by account and time. Join customer records and aggregate the result.
Query the recordsDeclare account and counterparty references, then traverse the relationships with a bounded query.
Follow a relationshipFind exact terms or rank matching passages. Keep the document ID with every search result.
Search policy textRetrieve similar text using your embeddings, then fetch the source passage for review.
Model the embeddingsText indexes and vectors use their own write endpoints. Your ingestion pipeline manages their updates and records the source version.
A focused first build
Use representative sample records before introducing customer data.
Review the design with usModel accounts, transfers, counterparties and source documents with stable IDs.
Schema referenceQuery the transfers, traverse their references, and check every returned source. Set result and traversal limits.
Graph quickstartKeep credentials server-side. Apply the application's access rules and retain the analyst's decision with its evidence.
Authentication reference