Industry Vocabulary Reference

Banking & Financial Services

Banking and financial services field names and values for recorded workflows. The catalog includes payments, lending, fraud, treasury, customer lifecycle, model risk, regulatory capital, and digital assets. Use these values in OTel span attributes and mapped policy inputs; they do not establish regulatory compliance.

Back to industry coverage library

This page shows selected examples and categories. Download the JSON for the complete vocabulary, including every field, permitted value, and policy pattern in this catalog.

How to use this reference

1. Start with the core file if you need the cross-industry governance baseline.
2. Choose an industry file for its workflow fields and permitted values.
3. Match the OTel attributes to the policy paths your rules use, then verify the recorded fields in a test session.

Catalog context

Use this vocabulary to describe workflows such as payment fraud screening, loan underwriting, customer onboarding, and model validation. Select fields that your integration can report reliably. Your compliance team must determine which requirements apply; recording a field does not satisfy those requirements.

Vocabulary file

• Download filename: 01_vertical_banking_financial_services.json
• Kind: vertical

OTel namespaces

Referenced standards

These references explain the catalog's context. A listed standard does not establish that a configured application meets its requirements.

• BIAN v13 / v14 (Banking Industry Architecture Network)
• ISO 20022, Universal financial industry message scheme
• Basel III, BCBS finalisation framework; implementation varies by jurisdiction
• EU DORA, Digital Operational Resilience Act (2022/2554, effective Jan 2025)
• FATF Recommendations, AML/CFT (updated 2023)
• EU 6AMLD, Sixth Anti-Money Laundering Directive
• FinCEN / BSA, Bank Secrecy Act SAR requirements
• PCI DSS v4.0, Payment Card Industry Data Security Standard
• SWIFT CBPR+, Cross-Border Payments and Reporting Plus (coexistence ended Nov 2025)
• FedNow, Federal Reserve real-time payment service ISO 20022 profile
• SEPA, Single Euro Payments Area rulebooks

Source references

• https://bian.org/deliverables/bian-standards/ 
• https://www.iso20022.org/iso-20022-message-definitions 
• https://www.bis.org/bcbs/publ/d424_hlsummary.pdf 
• https://www.eba.europa.eu/regulation-and-policy/operational-resilience/digital-operational-resilience-act-dora 
• https://explore.fednow.org/resources/readiness-guide-iso-20022.pdf 
• https://www.swift.com/standards/iso-20022/iso-20022-financial-institutions-focus-payments-instructions 

Subdomains

Implementation examples

• Payments & Funds Transfer: Payment Rail Type. OPA rule: require enhanced OFAC/sanctions screening for swift_cbpr_plus, sepa_credit_transfer, and sepa_instant rails. Require 24/7 HITL coverage for fednow and rtp_tcf rails above configurable threshold. (Fednow: Federal Reserve FedNow Service Operating Procedures)
• Payments & Funds Transfer: Payment Agent Action Type. OPA rule: classify initiate_credit_transfer, initiate_direct_debit, and apply_fx_conversion as irreversible_high_impact, requiring HITL approval above configurable amount threshold. (Psd2: PSD2 Article 64, Liability for unauthorized payment transactions)
• Payments & Funds Transfer: Sanctions Screening Outcome. OPA rule: deny any payment agent tool call for payment rail execution when sanctions_screening_outcome is potential_hit or confirmed_hit; require HITL escalation. (Ofac: OFAC 31 CFR Part 501, Reporting and procedures for blocked transactions)
• Fraud Detection & Financial Crime: AMLAlert Status. OPA rule: require HITL with compliance_officer role for sar_decision_pending state. Block automated sar_filed or sar_declined_documented transitions, these must be human-authorised. (Bsa 31 Usc 5318: BSA 31 USC 5318(g), Suspicious Activity Report filing obligation)

Control ideas

These patterns describe possible controls, not active rules. Confirm applicability, implement the control, and test its effect on the application.

Enforce before the action

Pass the request and your business action to this function. The core SDK checks policy before the action runs and again before its result is released. A deny or review decision means the action never runs.

import { Veriproof } from '@veriproof/sdk-core';
import type { GovernedResult, IndustryFact, JsonValue } from '@veriproof/sdk-core';

const veriproof = Veriproof.fromEnv();

export async function runProtectedAction<TInput extends JsonValue, TValue>(
  request: TInput,
  action: (input: TInput, signal: AbortSignal) => Promise<TValue>,
): Promise<GovernedResult<TValue, TInput>> {
  // Catalog values for this vertical. Replace them with facts from the current workflow.
  const industry: IndustryFact[] = [
    { attribute: "banking.payment.rail", policyInput: "banking_payment_rail", value: "fednow" },
    { attribute: "banking.payment.agent_action", policyInput: "banking_payment_agent_action", value: "initiate_credit_transfer" },
    { attribute: "banking.sanctions.screening_outcome", policyInput: "banking_sanctions_screening_outcome", value: "clear" },
  ];

  // Policy runs before action() and again before the result is released.
  // A deny or review decision means action() never runs.
  return veriproof.govern(
    "banking.financial.services.evaluate",
    request,
    ({ input, signal }) => action(input, signal),
    { industry },
  );
}

• Replace the sample values with facts from the current workflow. Rules read them under input.snapshot.industry.
• Test both permitted and blocked actions. Confirm that a blocked action never reaches your business function.
• Only completed, completed_with_warning, and transformed results carry a released value.

For review decisions, follow the Human Review guide to configure continuation. Observe remains available when you need to record activity without enforcing a decision.

Set up the Banking & Financial Services example. See the API reference for TypeScript, Python, or .NET.

Selected vocabulary categories

This page uses the vocabulary JSON distributed with the documentation. Check its version when comparing it with an installed SDK.

Download the vocabulary JSON for offline review or automated comparisons.

Use the SDK reference for configuration and supported APIs. Keep vocabulary selection separate from the compliance team's assessment of applicable requirements.