How banks and fintech companies can connect business meaning, financial data, enterprise knowledge and tools to build agents that investigate, recommend and coordinate action.
A banking agent needs to know what “this customer” means before it can explain what changed—and what should happen next.
Financial intelligence brings customer economics into view. Agentic AI builds on that foundation by connecting business relationships, evidence and tools into a workflow that can investigate a problem and coordinate a response.
Give the agent a business model, a clear goal and a controlled path to action.
This reference architecture follows a Customer Relationship Intelligence Agent from a profitability question to an approved follow-up task. The concepts, figures and interactions are illustrative, with no client data or live system connections.
1. Give the agent a business goal
A relationship manager sees a decline in a corporate customer’s contribution. Explaining it may require group ownership data, product-level financial measures, contract terms and service history. The work spans systems and several kinds of evidence.
An agentic workflow turns that request into a sequence of decisions: establish the scope, identify the right measures, retrieve context, calculate changes and prepare a response with specific next steps.
This article develops a banking reference architecture using a fictional customer group. In a fintech setting, the same pattern could connect merchant groups, settlement accounts, payment products, service agreements and account owners.
2. Connect reasoning to the right capabilities
In a banking engagement, NorthBay built executive and Customer 360 dashboards around revenue and expense datasets. The Cortex Agents provides the orchestration layer: it selects tools, uses their results and decides whether further work is needed. Structured queries, document retrieval and calculations become steps in a shared workflow. Snowflake CoWork provides a business-user experience, while the Agents API supports a custom application.
Cortex Agents documentation ↗ Snowflake CoWork documentation ↗
| Understand the business |
Ontology mappings + Semantic Views
|
| Find evidence |
Cortex Analyst + Cortex Search
|
| Investigate |
Cortex Agents + code execution
|
| Coordinate action |
Custom tools + MCP connectors
|
| Improve the workflow |
Agent evaluations + monitoring + CoCo
|
In this blueprint, the agent begins with read access to the approved customer and financial scope. A separately controlled action tool handles task creation after a reviewer approves the proposed payload.
3. Give the agent a model of the banking relationship
An ontology makes domain concepts and their relationships explicit. In banking, “customer” might mean a legal entity, an account holder or an entire corporate group. Those meanings lead to different scopes and different answers.
Our example distinguishes a corporate group from its legal entities, connects each entity to accounts, links accounts to products and financial entries, and associates contracts and relationship owners with the appropriate entity. Effective dates matter: a subsidiary acquired this quarter may not belong in last quarter’s group totals.
Snowflake’s engineering work demonstrates ways to add ontology context to Cortex Agents, including terminology mappings and graph-based retrieval. These are implementation approaches that complement analytical semantics. Ontology-grounded reasoning with Cortex Agents documentation ↗
Corporate group
Corporate group → contains → Legal entity
What the agent can resolve
Which entities belong in the group-level investigation?
Required control
Use canonical group IDs and effective-dated membership; apply the user’s permitted scope.
Legal entity
Legal entity → holds → Account; Legal entity → party to → Contract
What the agent can resolve
Which records refer to the same legal customer across systems?
Required control
Resolve aliases against maintained identifiers. Ask for clarification when the match is uncertain.
Account
Account → held by → Legal entity; Account → associated with → Product
What the agent can resolve
Which accounts and products belong to the selected entities?
Required control
Respect joint ownership and validity dates. Prevent duplicate aggregation across relationships.
Product
Product → classifies → Account service; Product → belongs to → Product family
What the agent can resolve
Which product families contribute to the financial change?
Required control
Maintain stable product classifications and explain taxonomy changes between periods.
Financial entry
Financial entry → posted to → Account; Financial entry → classified as → Revenue / Expense
What the agent can resolve
Which recorded amounts explain the contribution movement?
Required control
Validate grain, sign, currency and inclusion rules. Preserve the link to source records.
Contract
Contract → has party → Legal entity; Contract → has version → Effective terms
What the agent can resolve
Which agreement and amendments applied during the reporting period?
Required control
Validate grain, sign, currency and inclusion rules. Preserve the link to source records.
Service Record
Service record → concerns → Account / Legal entity
What the agent can resolve
Was there recorded service activity that deserves investigation alongside the cost change?
Required control
Match the entity and dates. Keep documented activity separate from unsupported cost attribution.
Relationship Owner
Relationship owner → manages → Corporate group / Legal entity
What the agent can resolve
Who should receive the proposed follow-up task?
Required control
Check current assignment and destination permissions before drafting or executing the action.
4. Separate ontology, analytical semantics and evidence
These layers answer different questions. Designing them together gives the agent a consistent route from a business phrase to a measurable result and its supporting context.
| Three complementary forms of business context | ||
|---|---|---|
| Layer | What it expresses | Role in this workflow |
| Ontology | Concepts, typed relationships, hierarchies and domain constraints. | Resolve “customer group,” membership and the relevant account relationships. |
| Semantic Views | Logical tables, relationships, dimensions, facts and metrics over analytical data. | Query agreed contribution, income and cost measures at the right grain. |
| Knowledge graph | A representation of connected entities and relationships. | Support explicit relationship traversal when the use case needs it. |
A Semantic View can capture substantial business meaning without being a complete ontology. A knowledge graph is one way to represent connected context; a carefully maintained mapping table may be sufficient for a simpler domain. Semantic Views documentation ↗
Start with canonical identifiers, aliases, relationship types, effective dates and the financial measures required by the first workflow. Map them to the underlying data. Where graph traversal or formal reasoning is needed, expose a tested query or custom tool that returns a bounded, traceable result.
Use Cortex Search for document evidence such as contracts and service records. Attach entity identifiers, document versions and effective dates to retrieved material so the agent can distinguish an active agreement from an expired one. Cortex Search with Cortex Agents documentation ↗
Keep meaning and enforcement separate. An ontology explains relationships and constraints. Authorization must be enforced by the data platform, retrieval configuration and action services.
5. Follow the investigation from goal to verified action
The following walkthrough shows an example execution path. A real agent may revisit a step, request clarification or stop when evidence is incomplete. The important property is that every step produces an inspectable result.
Customer Relationship Intelligence Agent
Inside the agentic workflow
Explore six steps using fictional records. This illustration has no live data connection and performs no external actions.
The financial bridge: 300 → 180 contribution. Revenue fell by 80 units and expenses rose by 40 units, explaining the 120-unit change. An agent must distinguish this measured decomposition from a claim about why the changes occurred.
6. Establish who is acting and what they may do
The ontology resolves the identity of the customer being investigated. Execution identity establishes which human or agent is requesting access. A customer relationship in the ontology does not grant permission to read that customer’s records.
Snowflake Horizon Catalog and native access controls provide the governance foundation: classification, lineage, role-based privileges, row access policies and masking. Enterprise SSO establishes human identity; provisioning and role assignments connect that identity to permitted resources. Horizon Catalog ↗ Access control ↗
Snowflake can identify agent-active sessions and attribute activity in query and access histories. These controls let a bank distinguish human access from agent-driven access and apply a tighter boundary to the agent. Configure and test that boundary for the chosen authentication and execution path. Agent identity and restricted sessions ↗
For readers familiar with Databricks: Horizon Catalog plus Snowflake’s native security controls is the closest comparison to Unity Catalog. Both govern access to data and AI assets; enterprise identity providers establish who the users are. The specific execution identity and tool permissions still need to be designed. Unity Catalog overview
7. Secure every retrieval and tool boundary
Authorization must follow the execution path. Validate the role used for analytical queries, the access scope of each search service, the execution rights of stored procedures and the credentials used by external tools. A successful agent sign-in does not establish all of these permissions.
Cortex Search needs an explicit access design. Search services run with the owner’s rights. A role allowed to query a service can retrieve indexed content even when it cannot read the underlying source tables. Source-table permissions therefore do not automatically provide per-user document filtering. Use appropriately scoped services and trusted authorization enforcement; agent-selected filters are not a security boundary. Cortex Search security requirements ↗
In this banking blueprint, contract and service-record retrieval is restricted to an approved corpus for the authorized relationship scope. Retrieved text is treated as evidence: instructions embedded in a document cannot expand the agent’s permissions or authorize an action.
For external operations, use scoped credentials, validate inputs on the server and recheck destination permissions at execution. Allow only the intended operation and fields. Keep secrets out of prompts and redact sensitive content in application logs. These are implementation controls that complement Snowflake’s native policies.
8. Give actions an explicit execution boundary
MCP connectors let Cortex Agents discover and invoke tools in external applications. Custom tools can expose institution-specific operations. For this workflow, the useful action is a relationship-management task with an owner, evidence and a next step. MCP connectors documentation ↗
Design the action interface around a narrow operation such as “create an approved follow-up task.” Validate its inputs on the server, check authorization at execution time and return an operation identifier that can be verified.
The approval step is part of this reference architecture’s application and tool design; connecting an MCP server alone does not create that control. Credit decisions, pricing changes and financial transactions are outside this example’s permitted actions.
9. Compose expertise with focused tools and skills
Organize capabilities around responsibilities: customer identity, financial analysis, document evidence and action execution. Give each one a defined input, output and access scope. That makes it easier to test a capability independently and reuse it across workflows.
Snowflake agent toolsets can inherit tools from other configured agents. The tools are combined for the calling orchestrator; this is tool composition, rather than an automatic delegation to independently reasoning agents. Agent toolsets documentation ↗
If a workflow needs separate agents to hand off work, explicitly design the coordination, shared state, failure handling and completion criteria. Start with one orchestrator and focused tools when that is sufficient.
Agent skills add reusable instructions and scripts for recurring tasks. A financial-investigation skill might define the required comparison checks and report structure, while calculation and action tools enforce the underlying operations.
10. Use agentic engineering to build and improve the workflow
Snowflake CoCo supports development work across data engineering, analytics and agent building. Use it to accelerate the implementation work around the agent: draft semantic models, author queries, refine tool specifications and help investigate failed tests. Snowflake CoCo documentation ↗
The engineering loop should stay concrete: define a representative banking question, build the minimum context and tools needed, run it against known results, inspect the trace and correct the failing layer.
Define the task → Build context & tools → Evaluate → Review & version
Keep ontology mappings, semantic definitions, tool contracts and evaluation cases versioned together. When a customer hierarchy or profitability rule changes, the team needs to know which answers and actions may be affected.
11. Observe the run, then evaluate its quality
Cortex Agent evaluations support testing against expected results and other quality criteria, including tool-related metrics for supported tools. Live monitoring provides traces for investigating actual runs. Use both to establish where an error arose and whether a change improved the workflow. Cortex Agent evaluations documentation ↗ Agent monitoring documentation ↗
Make each run inspectable
Cortex Agent monitoring records execution traces with tool calls, SQL activity, responses and feedback. Query and access histories provide a complementary view of who accessed which objects. Connect these records to the application’s approval and external-action receipts using correlation identifiers. External approval and business-system events require their own instrumentation.
| Who requested it? | User, agent identity, execution role and permitted scope |
| What informed it? |
Entity mappings, metric definitions, queries and document references
|
| What happened? |
Tool calls, denials, retries, elapsed time and errors
|
| Who approved it? |
Reviewer, timestamp and the exact approved action payload
|
| Was it completed? |
Destination record, deduplication key and verified read-back
|
Protect the observation layer too. Agent traces can contain prompts, retrieved information and tool outputs. Grant monitoring access deliberately and control access to unredacted content. Define retention and redaction for any exported logs.
Monitor business and operating quality
Track reconciliation failures, unsupported explanations, denied access, tool failures, approval delays and duplicate-action attempts. Establish latency and cost budgets, route actionable alerts to an owner and pause execution when the action service cannot verify a safe outcome. These operating thresholds and responses are part of the solution design.
| Example acceptance checks for a banking agent | |
|---|---|
| Check | What a useful test verifies |
| Customer identity & scope | The right entities are included for each date; ambiguous names are clarified. |
| Execution identity & access | Unauthorized entities and documents are denied; sensitive fields stay masked; agent privileges remain within their configured ceiling. |
| Financial accuracy | Totals, comparison periods, currency and contribution definitions reconcile. |
| Evidence quality | Documents match the entity and time period; missing evidence is stated. |
| Tool behavior | The agent selects relevant tools and handles empty, denied or failed results. |
| Action control | No task is created without the required approval; retries do not duplicate records. |
| Operating quality | Column 2 Value 8 |
Use targeted integration tests for approval enforcement, permissions and retry behavior. Include adversarial document content, stale ownership mappings and partially available data. A correct final paragraph is insufficient if the workflow crossed an access boundary or created the wrong task.
12. Expand autonomy in measured steps
FAQs
About NorthBay Solutions
NorthBay Solutions is a leading provider of cutting-edge technology solutions, specializing in Agentic AI, Generative AI MSP, Generative AI, Cloud Migration, ML/AI, Data Lakes and Analytics, and Managed Services. As an AWS Premier Partner, we leverage the power of the cloud to deliver innovative and scalable solutions to clients across various industries, including Healthcare, Fintech, Logistics, Manufacturing, Retail, and Education.
Our commitment to AWS extends to our partnerships with industry-leading companies like CloudRail-IIOT, RiverMeadow, and Snowflake. These collaborations enable us to offer comprehensive and tailored solutions that seamlessly integrate with AWS services, providing our clients with the best possible value and flexibility.
With a global footprint spanning the NAMER (US & Canada), MEA (Kuwait, Qatar, UAE, KSA & Africa), Turkey, APAC (including Indonesia, Singapore, and Hong Kong), NorthBay Solutions is committed to providing exceptional service and support to businesses worldwide.
