Skip to main content
In fintech, the difference between a deposit and revenue is fundamental, yet often misinterpreted by LLMs without additional tuning. To provide accurate insights, your model needs to define the “Golden Rules” of your ledger, specifically how signs (positive vs. negative) and transaction statuses are interpreted. By embedding your fintech-specific logic directly into the model, topic, and view layers, you ensure that Omni’s AI operates as a specialized financial analyst. This structured approach reduces hallucinations in critical reporting like AUM, delinquency rates, and net worth calculations.

Why AI context matters

Fintech data is notoriously nuanced. Without specific context, AI might:
  • Treat a loan balance as a positive asset for a customer
  • Double-count internal ACH transfers as revenue
  • Misinterpret liability-centric ledger conventions
By providing explicit guardrails, you ensure Omni’s AI operates as a specialized financial analyst that understands liability-centric ledgers and regulatory risk states.

The AI context hierarchy

Omni allows you to layer context at different levels of your data model. For fintech, this hierarchy ensures that global rules (like currency) are respected while specific logic (like loan delinquency) is applied only where relevant.
LayerPurposeExample
ModelUniversal truths. Global business logic and formatting rules that apply to all queries in the model.”Inflows are positive and outflows are negative; use USD for all reporting”
TopicThe persona. Definitions for specific datasets and how views relate to each other.”AUM includes all positive balances; exclude internal transfers from net volume.”
View/FieldField precision. Specific definitions, synonyms, and allowed values for columns.”This view tracks credit health; ‘delinquent’ and ‘late’ statuses are At-Risk.”

Requirements

To implement this example in your own Omni instance, you’ll need:
  • Familiarity with Omni’s modeling layer
  • Permissions in Omni that allow you to edit a shared model
  • A connected data source that contains fintech or banking-related data
1

Setting universal rules in the model file

The model file is where you establish your “Golden Rules.” These rules apply across every query the AI generates, ensuring consistent handling of inflows, outflows, and reporting currencies.
# Model File
ai_context: |
  ## Strategic Overview
  This model serves as the unified ledger and relationship management for a multi-entity financial platform. 
  It bridges Retail Banking (Individual), Commercial Banking (Business), and Lending operations.
  
  ## Financial Guardrails
  - **The Golden Rule of Signs**: In this model, 'Accounts' and 'Transactions' follow a liability-centric ledger. 
    - Credits (deposits/inflows) are POSITIVE. 
    - Debits (spend/outflows/payments) are NEGATIVE. 
    - Loan/Credit Card balances are represented as NEGATIVE (money owed to the institution).
  - **Transaction vs. Settlement**: All dates are 'Transaction Dates'. For 'Settlement' logic, assume a T+2 window unless analyzing 'Card Transactions' which are near-instant.
  - 'Transfer' categories and 'ACH' transactions between a user's own accounts must be excluded from 'Revenue' and 'Net Spend' to avoid double-counting.
  
  ## Entity Relationships
  - All analysis begins with the 'Customer'. A single customer_id may own multiple account_types (Checking, Mortgage, etc.). 
  - 'Product' labels (e.g., 'Mass Affluent' vs. 'Startup') dictate the fee structures and risk profiles. 
  
  ## Regulatory & Risk Context
  - **Delinquency State**: Any account joined to a 'Loan' with a status of 'delinquent' or 'late' should be flagged in 'At-Risk' reporting.
  - **Reporting Currency**: All values are denominated in USD. No FX conversion is required.
2

Setting dataset logic in the topic

Topics represent the “Customer 360” view. Use the topic-level ai_context to define calculated metrics like Assets Under Management (AUM) or Wallet Share so the AI doesn’t have to guess which accounts to include in a balance check.
base_view: fintech_dataset_main__customers
label: Customer & Banking activity

description: |
  Customer 360 topic for consumer and business banking relationships.
  This topic combines customer profile, account balances, transaction behavior, and lending status so analysts can answer lifecycle questions like: acquisition, activity, wallet share, risk, and profitability.
  
  It is designed for both Retail (high-frequency card/ACH behavior) and
  Business banking (higher-value wire/ACH flows), with loan performance
  included for portfolio risk and delinquency monitoring.
  Typical use cases:
  - Active customer tracking and cohort/vintage analysis
  - AUM and balance composition by customer segment
  - Spend and flow analysis by channel/category
  - Delinquency and at-risk customer identification

ai_context: |  
  ## Business Guardrails & Logic
  - **Revenue vs. Volume**: 'Revenue' refers to fees/interest earned by the bank. 'Transaction Volume' or 'GTV' refers to the total flow of money through the platform. Do not confuse the two.
  - **Asset vs. Liability**: For the bank, 'Checking/Savings' are liabilities (we owe the customer), and 'Loans/Mortgages' are assets. However, for 'Customer Net Worth' calculations, treat Checking/Savings as (+) and Loans/Credit Card balances as (-).
  - **Active Customers**: Define 'Active' as a customer with at least one transaction in the last 30 days, or a non-zero balance in a 'Checking' or 'Savings' account.
  
  ## Product Context
  - **Individual vs. Business**: Individual accounts are high-volume, lower-balance (Retail). Business accounts (Startups/Enterprise) have higher 'Wire' and 'ACH' volumes.
  - **Churn**: A customer is considered 'Churned' if all their accounts have a 'closed' status and zero balance.
  - **Risk**: Use 'delinquent' status in Loans to identify at-risk portfolios. 'Delinquency Rate' is (Count of Delinquent Loans / Total Active Loans).
3

Adding precision at the view level

View-level context handles the specific quirks of your tables. For example, you can instruct the AI to ignore certain dimensions (like birth years) when analyzing business entities or define which specific statuses represent a “total loss” for the bank.
catalog: fintech_dataset
schema: main
table_name: customers

description: |
  Master customer entity table. Each row represents a KYC-verified
  individual or business relationship with the institution.
  
  Use this table as the starting point for customer lifecycle, segmentation,
  onboarding cohort, and relationship-level analytics.

ai_context: |
  The 'Entity' or 'User' master table. This is the starting point for 
  all Relationship Management and Growth analytics.
  
  ## Business Logic
  - 'Individual' types are retail consumers; 'Business' types are commercial entities.
  - 'birth_year' is only valid for 'Individual' types; do not use for Business analysis.
  - 'created_at' represents the completion of KYC (Know Your Customer) and account opening.
  - Use 'created_at' to define 'Customer Vintages' (cohorts based on signup date).

dimensions:
  customer_id:
    primary_key: true
    type: string
    sql: '"customer_id"'
    description: Unique identifier for the KYC-verified customer entity.
    ai_context: |
      "The unique identifier for the KYC-verified entity."

  type:
    type: string
    sql: '"type"'
    all_values: ['individual', 'business']
    description: Legal customer type indicating whether the account holder is an individual or a business.
    ai_context: |
      "Categorizes the legal nature of the account holder."

  name:
    type: string
    sql: '"name"'
    description: Full legal name of the customer (person or registered business entity).
    ai_context: |
      "The full legal name (Individual) or registered entity name (Business)."

  segment:
    type: string
    sql: '"segment"'
    all_values: ['mass', 'mass_affluent', 'affluent', 'high_net_worth', 'startup', 'small_business', 'mid_market', 'enterprise']
    synonyms: ['wealth bracket', 'tier', 'client profile']
    description: Customer tier used for relationship strategy, service model, and performance analysis (e.g., mass, affluent, startup, enterprise).
    ai_context: |
      Hierarchical value. 
      Individual: mass < mass_affluent < affluent < high_net_worth.
      Business: startup < small_business < mid_market < enterprise.

  state:
    type: string
    sql: '"state"'
    all_values: ['CA', 'TX', 'NY', 'FL', 'IL', 'PA', 'OH', 'GA', 'NC', 'WA']
    description: Two-letter U.S. state code representing the customer’s primary location for geographic analysis and risk concentration.
	ai_context: |
      "Two-letter US State code for geographic concentration risk."

  created_at:
    type: date
    sql: '"created_at"'
    synonyms: ['onboarding_date', 'activation_date', 'signup_date']
    description: Date the customer relationship was activated (KYC/account onboarding completion).
    ai_context: |
      "The date the customer record was finalized in the system."

  birth_year:
    type: number
    sql: '"birth_year"'
    description: Birth year of the customer for individual records; typically null for business entities.
    ai_context: |
      "Birth year for Individuals; NULL for Business entities."

catalog: fintech_dataset
schema: main
table_name: transactions

description: |
  Banking transactions ledger. Each row is a posted money movement event
  for a customer account.
  
  A transaction is either:
  - **Deposit/Credit (positive amount)**: money entering the account
  - **Withdrawal/Debit (negative amount)**: money leaving the account
  This table is used for spend analysis, inflow/outflow trends, channel mix,
  merchant behavior, and customer activity scoring.

ai_context: |
  The source of truth for transactional flow.
  - Negative amounts = outflows (spend/payments)
  - Positive amounts = inflows (deposits/refunds)
  - Category='Transfer' indicates internal movement; exclude from revenue
  - account_id links each transaction to a specific product/account

dimensions:
  transaction_id:
	primary_key: true
    type: string
    sql: '"transaction_id"'
    description: Unique transaction event identifier.
    ai_context: Stable primary key for each posted transaction row.
  
  customer_id:
   	type: string
    sql: '"customer_id"'
    description: Customer who initiated or received the transaction.
    ai_context: Foreign key to customer entity; use for customer-level aggregations.

  account_id:
	type: string
    sql: '"account_id"'
    description: Account on which the transaction was recorded.
    ai_context: Foreign key to account/product; use for checking vs card vs loan analysis.

  amount_usd:
	type: number
    sql: '"amount_usd"'
    synonyms: ['value', 'flow', 'transaction_size']
    description: Signed transaction amount in USD.
    ai_context: Positive = deposit/credit (inflow). Negative = withdrawal/debit (outflow).

  category:
	type: string
    sql: '"category"'
    all_values: ['Groceries', 'Restaurants', 'Transfer', 'Travel', 'Entertainment', 'Utilities', 'Payroll', 'Rent', 'Insurance']
    description: Business classification of transaction purpose.
    ai_context: Use to segment spend/flow; treat 'Transfer' as internal movement.

  merchant:
	type: string
    sql: '"merchant"'
    description: Counterparty or merchant name associated with the transaction.
    ai_context: Useful for concentration and behavioral analysis; fuzzy matching may be needed.

  channel:
	type: string
    sql: '"channel"'
    all_values: ['ach', 'wire', 'card', 'mobile', 'web', 'branch']
    description: Payment rail or origination channel for the transaction.
    ai_context: ach/wire/card/mobile/web/branch indicate different customer behaviors.

  date:
	type: date
    sql: '"date"'
    description: Posting/settlement date of the transaction.
    ai_context: Canonical date for trend and period-over-period analysis.

Iterating on AI context

Improving AI quality is an iterative process. As you launch new financial products or change your lending criteria, update your context. Think of AI context as living documentation for your ledger: the more precise you are, the less time your team spends making corrections. Iteration involves a feedback loop between user queries and model updates:
  1. Monitor: Use the AI usage dashboard in the Analytics section to find queries with negative (👎) feedback.
  2. Identify: Did the AI fail due to a cryptic name, a missing join, or a lack of business logic?
  3. Tune: Update the YAML at the appropriate level (model, topic, view).
  4. Verify: Re-run the prompt in the Query Helper to ensure changes work as expected.
  5. Update for product launches: When your platform introduces a new payment rail like FedNow or a new loan product, update the all_values and ai_context parameters to reflect the new taxonomy.
When you correct the AI in a chat session (e.g., "Actually, always use Fiscal Year"), click the (brain) icon to have the AI learn from the conversation and propose model changes to incorporate the correction.

Next steps