Prepare Your Banking Data Model

[Nick Daigneau]

Objective

Understand how to prepare a banking data model for a Financial Services Operations (FSO) implementation. This article expands on foundational concepts introduced in Getting Started with Banking Service Management by exploring Customer Data Foundations, Service Model Foundations, Financial Services Operations Core, and Case Management configuration in greater technical depth. It also covers integration best practices — including lookup & save patterns and remote tables — to help implementation teams make informed architectural decisions early. Use this guide to establish a solid data foundation before configuring FSO applications.

Overview

Before diving into individual components, it is critical to understand how FSO's data model pieces fit together.

The core relationships can be summarized as follows:

The People

• Customer records (Accounts, Contacts, Consumers, Households) represent who the bank serves
• Advisors and Contributors are the members that service customers (e.g. Relationship Managers, Branch Bankers, Financial Advisors, Branch staff). These members are part of internal or external entities that support the value chain (e.g. branches) and can sit within physical sites (e.g. branch location, service centers)
• Agents are the day-to-day operational users in ServiceNow (contact center reps, dispute analysts, fraud investigators, etc.) who work cases, complete tasks, and execute processes to resolve customer needs

The Products

• Product Models define the catalog of offerings for the Bank (e.g. deposit accounts, loans, cards)
• Financial Accounts link customers to the specific products they hold
• Financial Transactions capture debit and credit activity against financial accounts
• Financial Services represent specific banking capabilities enabled on a financial account (e.g. Remote Deposit Capture, Wire Transfer, Bill Pay)

The Work

• Interactions and Cases tie back to customers and their financial accounts, representing why they are contacting the bank

These are not isolated tables — they form an interconnected web. A Consumer can belong to a Household, hold multiple Financial Accounts, each tied to a Financial Product, and any of those relationships can spawn Cases. Understanding these connections before you start configuring prevents rework later.

Learn more: Introduction to FSO Core | Understanding FSO Core Relationships | Banking Tables

 

The People

Recap on Personas

Financial Services Operations brings together three key groups of people who interact with the platform and each other to deliver financial services. As mentioned above, Customers represent the individuals, households, and organizations receiving services from the institution. Advisors and contributors are the bankers, relationship managers, and branch staff who maintain the customer relationship and act as the bridge between the customer and the organization. Agents are the operational users who perform the day to day work within the platform, such as resolving cases, processing requests, and completing investigations. Together, these three personas define who the organization serves, who manages the relationship, and who executes the work required to deliver service.

Customers

In ServiceNow Financial Services Operations, customers are modeled through Customer Data Foundation (CDF), which provides the core data structures used to represent external parties. CDF includes entities such as Consumers, Contacts, Accounts, and Households, allowing the platform to represent both retail and commercial relationships. This model defines who the organization serves and how customers are related to one another. It provides the foundation for customer context across service interactions, financial products, and service requests. Customers may engage with the institution through digital channels, contact centers, or branches, and their requests ultimately drive the work managed within the platform.

Advisors and Contributors

Advisors and contributors represent the people within the financial institution who maintain relationships with customers and are accountable for the overall service experience. These roles include relationship managers, branch bankers, financial advisors, and other contributors who support customer servicing outside the traditional contact center model. 

These personas are modeled through Service Model Foundation (SMF). SMF defines the organizational structures that connect people to service organizations such as branches, operations teams, and partner organizations. It establishes how individuals relate to business locations and service organizations and defines responsibilities and relationships that control customer visibility and service ownership. Through SMF, organizations can represent which advisors are assigned to specific customers or accounts, which branch they belong to, and how service responsibilities are structured across teams.

Agents

Agents are the operational users who perform the day-to-day work required to service customer requests within the platform. These roles typically include contact center representatives, operations specialists, dispute analysts, fraud investigators, and servicing teams. Unlike advisors, agents are not modeled through the Service Model Foundation. Instead, agents are represented as users within the ServiceNow platform and are granted agent specific roles and permissions that determine what work they can perform and what data they can access.

Agents live directly within the operational workflows of the system, working cases, completing tasks, and executing processes that resolve customer needs. Their access, capabilities, and workspace experience are controlled through platform roles rather than organizational relationship modeling.

Customer Data Foundation

Customer Data Foundation (CDF) provides the tables and relationships to represent external customers. FSO inherits these structures from Customer Service Management (CSM), extended with financial services-specific attributes.

Core Tables

Table	Table Name	Purpose	Extends
Account	customer_account	B2B business customers	core_company
Contact	customer_contact	Individuals associated with business accounts	sys_user
Consumer	csm_consumer	B2C individual customers	—
Consumer User	csm_consumer_user	Consumer portal registration records	sys_user
Household	csm_household	Groups of related consumers	—

Key Configuration Decisions

Contacts vs. Consumers: Choosing the right model. The platform distinguishes between Contacts (B2B, extend sys_user, can log in) and Consumers (B2C, do not extend sys_user by default). For banks serving both retail and commercial customers, this creates a decision point:

• If a customer holds both personal and business accounts, should they be modeled as a Contact or Consumer?
• The community article Modeling a Consumer as a Contact with Financial Accounts outlines an approach where all external users start as Contact records, which simplifies identity management since Contacts extend sys_user and support login.

Household configuration. Households group related Consumers for a unified view of family relationships. Key fields include Primary Contact (the main point of contact for the household) and Members (related list of Consumers). Consider whether your core banking system provides household data or if this will be manually maintained in FSO.

Account hierarchies. For commercial banking, the Account table supports parent-subsidiary relationships. Configure these to represent legal entity structures and control entitlement inheritance.

Learn more: Customer Data Overview | Configuring Accounts and Contacts | Configuring Consumers | Configuring Households

 

Service Model Foundation

Service Model Foundation (SMF) extends beyond external customers to define the broader ecosystem of people and organizations involved in service delivery. For banking, this is particularly relevant for modeling branches, outsourced service providers, and internal teams that impact customer experience.

Core Tables

Table	Table Name	Purpose
Service Organization	sn_customer_service_organization	Internal or external entities in the support value chain (branches, operations centers)
Service Organization Member	sn_csm_service_organization_member	Links users to service organizations (branch staff, operations team members)
Business Location	sn_csm_business_location	Physical sites (External and Internal) including branches and service centers
Outsourced Service Provider	sn_outsourced_service_provider	Third-party BPOs or vendors contracted for specific service functions

Responsibilities, Relationships, and Roles

Beyond the core tables, SMF includes a framework of responsibilities, relationships, and roles that control how users interact with service organizations and customer data. Understanding these concepts is essential for configuring appropriate access controls and case visibility in banking environments.

• Responsibilities define what a user is authorized to do within a service organization or for a customer account. In banking, this might include designating a user as the "Primary Contact" for a commercial account, a "Branch Manager" with escalation authority, or a "Relationship Manager" responsible for a portfolio of wealth management clients. Responsibility definitions drive access controls and can be used to route cases to the appropriate party.
• Relationships define how entities connect to each other. Account relationships link parent and subsidiary companies (useful for commercial banking hierarchies). Contact relationships allow contacts to act on behalf of multiple accounts. Partner relationships enable channel partners like mortgage brokers to service customers on the bank's behalf. These relationships drive both data visibility and case routing.
• Tables store the underlying data for service organizations, members, and their associations. Key tables referenced above help implementation teams plan data imports, build integrations for employee data, and configure reporting on service delivery by branch or region.
• Roles control what actions users can perform and what data they can access. FSO provides internal roles (for bank employees like agents and managers) and external roles (for customers and partners accessing portals). In banking, role configuration determines whether a branch manager can view all cases in their branch, whether a relationship manager can act on behalf of their assigned customers, and whether a partner (like a mortgage broker) can create cases for their referred clients.

Key Configuration Decisions

• Branch modeling: Branches are a critical touchpoint in banking and should be represented in the data model for case routing, reporting, and agent context. Leverage Service Organizations & Internal / External Business Locations to support this.
• Seller and advisor personas: Unlike traditional contact center models, banking often involves relationship managers, branch bankers, and wealth advisors who serve customers outside the contact center. SMF supports this through Service Organization membership (which employees belong to which branches/teams) and Account Team relationships (which advisors are assigned to which customer accounts).
• B2B2C and B2B2B relationships. If your bank serves customers through intermediary partners (mortgage brokers, fintech platforms), configure Partner accounts and the associated relationship structures. Partner users can create cases on behalf of end customers with visibility controls ensuring partners see only their own customers and reporting segmented by partner channel.

Why Service Model Foundation Matters: The Branch Portal Example

Modeling a branch portal without Service Model Foundation is possible — but you'll quickly hit limitations that matter in banking. SMF gives your data model the structural backbone to reflect how banking actually works: specific locations, staffed by specific people, serving specific customers, handling specific products and services.

Here's what that unlocks in practice:

• Data separation by branch — Cases are associated with the branch where they originated, not just a generic queue, enabling accurate routing and reporting by location or region.
• Customers linked to locations — Customers and accounts can be associated with their servicing branch, so agents always have the right context and cases can be routed or filtered based on which branch owns that customer relationship.
• Staff and role modeling — Service Organizations group branch staff so a Branch Manager can see all cases for their location, a Relationship Manager can act on behalf of assigned customers, and partner users (like mortgage brokers) can submit cases for referred clients — all with the right access controls baked in.
• Location-aware assets and services — Assets and services can be tied to specific branches, so when a customer submits a request or a branch reports an issue (like a self-service kiosk), the location context is already there.
• Relationship-driven visibility — Responsibilities and Relationships control what each persona can see and do, without custom workarounds.

The branch portal below illustrates these concepts in action — built on a data model that reflects how your branches, people, and customers are actually connected.

Learn more: Service Model Foundation Overview | Service Model Foundation Responsibilities | Service Model Foundation Relationships | Service Model Foundation Tables | Service Model Foundation Roles

 

The Products

Product Foundation: The FSO Core Data Model

The FSO Core Data Model provides banking-specific tables built on the platform's Product Model and Sold Product foundations. Understanding this hierarchy is critical for implementation teams before configuring any FSO application.

Product Models

The FSO Core Data Model builds on the platform's Product Model [cmdb_model] hierarchy. Service Model [cmdb_service_product_model] extends Product Model, and all banking-specific product models extend from Service Model:

Product Model	Table Name
Card Account Model	sn_ent_card_service_model
Deposit Account Model	sn_ent_deposit_account_model
Financial Service Model	sn_ent_financial_services_model
Investment Model	sn_ent_investment_model
Line of Credit Model	sn_ent_line_of_credit_model
Loan Account Model	sn_ent_loan_account_model

These Product Models define the catalog of banking products your institution offers. They serve as templates that describe product features, terms, and configurations. When a customer acquires a product, the relationship between the Product Model and Customer creates the Financial Account.

Financial Accounts

When a customer relationship is established with a Product Model, a Financial Account [sn_bom_financial_account] is created. Financial Account extends Sold Product and links the customer to their specific product instance with account-specific details (account number, balance, status, open date). FSO provides extended account tables for different product types:

• Business Credit Card Account [sn_bom_b2b_credit_card]
• Personal Credit Card Account [sn_bom_credit_card]
• Deposit Account [sn_bom_deposit_account]
• Investment Account [sn_bom_investment_account]
• Line of Credit [sn_bom_line_of_credit]
• Loan Account [sn_bom_loan_account]

Each of these account types may have additional extensions. For example, Deposit Account is further extended for Checking vs. Savings accounts in both B2B and B2C contexts. Review the FSO Core Banking Tables documentation for the complete hierarchy.

Learn more: Understanding FSO Core relationships

Sold Product Related Parties

Sold Product Related Parties [sn_install_base_sold_product_related_party] is a critical concept for defining responsibilities against a financial account. This table links contacts or consumers to accounts with specific roles — such as joint owner, authorized signer, power of attorney, or beneficiary. Properly configuring related parties enables agents or front-office personas to identify who is authorized to act on an account and supports self-service scenarios where customers can view and manage accounts they are associated with.

Learn more: Add related parties to a sold product

Payment Card Data Model

One additional aspect to be aware of is the Payment Card [sn_payment_card_base] data model. Instead of extending Sold Product, this table extends Install Base Item [sn_install_base_item] to represent physical or virtual cards associated with a financial account. This table is further extended for Credit Card [sn_payment_card_credit] and Debit Card [sn_payment_card_debit], storing key card details such as card number, expiration date, and status. Payment Card data is critical for use cases like Card Disputes, where integrations need card-level information to process chargebacks, report fraud, or handle lost/stolen card requests.

Learn more: Payment card

Financial Services

Financial Service [sn_bom_service] extends Sold Product to represent specific banking capabilities enabled on a financial account. These are particularly relevant for Treasury Management and commercial banking. FSO provides extensions for common treasury services:

• RDC Service [sn_bom_rdc] — Remote Deposit Capture
• Wire Transfer Service [sn_bom_wire_transfer]

Financial Service User [sn_bom_financial_service_user] defines roles and responsibilities for users against a specific financial service. This enables banks to specify who is authorized to initiate wire transfers, approve RDC deposits, or manage other treasury services on behalf of a business account.

Financial Transactions

Financial Transaction [sn_bom_transaction] captures transaction-level data associated with financial accounts, providing agents with context when resolving disputes, inquiries, or fraud cases. Like Financial Accounts, transactions are extended for specific account types:

• Card Transaction [sn_bom_card_transaction]
• Deposit Transaction [sn_bom_deposit_transaction]
• Investment Transaction [sn_bom_investment_transaction]
• Line of Credit Transaction [sn_bom_line_of_credit_transaction]
• Loan Transaction [sn_bom_loan_transaction]

Other Useful Tables

The FSO Core Data Model includes additional tables to support specific banking use cases such as:

• Security [sn_bom_security] and Trade [sn_bom_trade] to support wealth management and brokerage scenarios by tracking investment holdings and buy/sell transactions, enabling agents to resolve portfolio inquiries, trade execution disputes, and settlement questions.
• Covenant [sn_bom_covenant_base] tracks loan covenants and compliance requirements for commercial lending, helping banks monitor borrower obligations and trigger proactive case creation when breaches are detected.
• Operating Instruction [sn_bom_operating_instruction] stores standing instructions for transaction handling, commonly used in treasury management to define settlement preferences, wire routing, and repetitive payment templates.

Review the full data model documentation to identify additional tables relevant to your implementation scope.

Learn more: Understanding FSO Core relationships

 

The Work

Case Management Foundation

Case Types and Service Definitions define why customers contact the bank and how those requests get resolved. FSO ships with pre-built case types and service definitions for each application, but implementation teams must understand when to use out-of-box configurations and when to extend.

Core Concepts

Case Types are extended case tables that inherit from the base CSM Case table [sn_customerservice_case]. Each FSO application ships with case types that include banking-specific fields (such as dispute amount, transaction date, and card number), pre-configured workflows, and application-specific business rules and UI policies.

The full list of case-related tables shipped out-of-the-box for each application is listed below. Note that this excludes other tables such as task-related tables extended from Financial Task. For more information on the purpose of each application, review Financial Services Operations (FSO) for Banking: Application Overview

• Business Lifecycle
  • Account Lifecycle Service Case [sn_bom_clo_b2b_account_service]
  • Contact Lifecycle Service Case [sn_bom_clo_b2b_contact_service]
• Card Operations (inclusive of Dispute Management)
  • Card Disputes Service Case [sn_bom_credit_card_disputes_service]
  • Credit Card Service [sn_bom_credit_card_service]
• Complaint Management
  • Complaint Case [sn_bom_compl_service]
• Credit Operations
  • Business Credit Service Case [sn_bom_credit_asmt_b2b_service]
  • Personal Credit Service Case [sn_bom_credit_asmt_service]
  • Business Loan Credit Service Case [sn_bom_credit_asmt_loan_b2b_service]
  • Personal Loan Credit Service Case [sn_bom_credit_asmt_loan_service]
• Client Lifecycle
  • Client Lifecycle Service Case [sn_bom_clo_b2c_service]
• Deposit Operations
  • Business Deposit Service Case [sn_bom_deposit_b2b_service]
  • Personal Deposit Service Case [sn_bom_deposit_b2c_service]
• Financial Services Operations Core
  • Financial Services Case [sn_bom_financial_service]
• Intelligent Servicing for Fraud
  • Fraud Case [sn_bom_fraud_case]
• Loan Operations
  • Business Loan Service Case [sn_bom_loan_b2b_service]
  • Personal Loan Service Case [sn_bom_loan_service]
• Payment Operations
  • Claim [sn_bom_payment_claim]
  • Payment Inquiry Case [sn_bom_payment_inquiry]
  • Payment Service [sn_bom_payment_service]
• Treasury Operations
  • RDC Service Case [sn_bom_treasury_rdc_service]
  • Wire Service Case [sn_bom_treasury_wire_service]

Service Definitions connect the "what" (the service a customer needs) to the "how" (the case type and workflow used to fulfill it). They drive record producers and catalog items for intake, routing rules for assignment, and reporting categorization. Multiple service definitions can exist within a single case type, enabling different intake experiences and processes while sharing the same underlying data structure.

The list of service definitions for each application is too long to put into this article but can easily be accessed by navigating to All > “Application Name” > Administration > Service Definitions within your ServiceNow instance. Below is an example for the Business Lifecycle application

Case Type Architecture

As briefly mentioned above, FSO case types follow a table hierarchy that extends from Financial Services Base [sn_bom_case], which in turn extends the CSM Case table [sn_customerservice_case]. This architecture ensures that all FSO cases inherit core platform capabilities while adding financial services-specific functionality.

Most FSO applications provide a base case type that is then extended for specific use cases. These are referenced below:

• Business Lifecycle
  • Business Lifecycle Base [sn_bom_clo_b2b_base]
• Card Operations (inclusive of Dispute Management)
  • Card Base [sn_bom_credit_card_case]
  • Personal Credit Card Base [sn_bom_credit_card_base]
• Complaint Management
  • Complaint Base [sn_bom_compl_base]
• Credit Operations
  • Credit Base [sn_bom_credit_asmt_base]
• Client Lifecycle
  • Client Lifecycle Base [sn_bom_clo_b2c_base]
• Deposit Operations
  • Deposit Base [sn_bom_deposit_b2b_base]
  • Deposit Base [sn_bom_deposit_b2c_base]
• Loan Operations
  • Loan Base [sn_bom_loan_b2b_base]
  • Loan Base [sn_bom_loan_base]
• Payment Operations
  • Payment Base [sn_bom_payment_base]
• Treasury Operations
  • Treasury Base [sn_bom_treasury_base]

These base tables provide the foundation that application-specific case types extend further.

Additionally, some FSO case types are designed to be used as-is without further extension. Financial Services Case [sn_bom_financial_service_case] and Fraud Case [sn_bom_fraud_case] fall into this category.

A case type in FSO encompasses four key components:

• Data Tables — Extended case tables that inherit from Financial Services Base [sn_bom_case], which itself extends the CSM Case table. This can also include Task tables that inherit from Financial Task [sn_bom_task], which itself extends from CSM task table.
• Views — Workspace experiences for agents, list views for different personas, and customer-facing portal experiences
• Process — Playbooks, UI Actions, UI Policies, Client Scripts, Business Rules, Notifications, and SLA Definitions that govern how the case moves from creation to resolution
• Permissions — User/Group assignments, Roles, and ACLs that control who can create, view, update, and resolve cases of this type

Important: If you need to create a new case type, it should always extend from Financial Services Base [sn_bom_case] or from the application’s respective base table. This ensures your custom case type inherits the FSO framework capabilities including workspace integration, reporting compatibility, and platform features designed for financial services workflows.

Learn more: Using Case Types and Service Definitions in FSO

Case Type vs. Service Definition: Making the Right Choice

A recommended exercise is to complete a Case Type Questionnaire for each request type the bank needs to support. This questionnaire captures key decision criteria that help determine whether to create a new case type or use a service definition within an existing case type:

• Unique Fields — Are there specific attributes required to process this work? How many?
• Process — Is there a unique workflow or process for this request type?
• Users — Is there a specific group that handles this work?
• Visibility — Can this work be seen by other groups, or is it restricted?
• SLA — Are there specific service level requirements?
• Related Tasks — Will there be associated tasks or child cases?
• Volume — How many requests are expected per year?
• Initiation — Who initiates these requests (customer, call center, back office)?
• Customer Visibility — Should customers see this work in self-service portals?

If two request types share the same fields, same assignment group, same visibility rules, and only differ in the process used to resolve them, a Service Definition within an existing case type is typically the right approach. However, if a request type requires numerous unique fields, different user access, restricted visibility, or a fundamentally different data model, a separate case type is warranted.

Learn more: Case Types in FSO | Extending FSO Case Types | Creating New FSO Case Types | Service Definitions in FSO

 

Integration Best Practices

Integration architecture is one of the most critical decisions in an FSO implementation once the data model has been setup. FSO is rarely the system of record for customer or account data — that typically lives in external / core banking systems. Implementation teams must determine how data flows between systems, what gets persisted in FSO, and what gets accessed in real-time.

Pattern	Description	When to Use	Considerations
Store Local	Scheduled jobs (batch) or real-time API calls import data from external systems into FSO tables	Master data that changes infrequently (customers, accounts, products)	Requires data mapping, transformation, and deduplication logic; data may be stale between syncs
Hybrid	Real-time API call retrieves data from external system and persists only what’s necessary into FSO	Data needed for case context that must be retained for audit/history or to trigger integrations within a given workflow (e.g. Disputes)	Creates data in FSO; requires sync strategy for updates
Fully Remote	Real-time API call retrieves data into memory within ServiceNow without persistence	Data needed for display only; data that changes frequently; compliance restrictions on data storage	No persistence — data exists only during session; ideal for balances, recent transactions, external system status

Integration Options

FSO provides multiple options for integrating with core banking systems and external data sources. The right approach depends on whether pre-built connectors exist, the data persistence requirements, and the specific use case.

Integration Hub Spokes

The preferred starting point for FSO integrations is leveraging Integration Hub Spokes. Spokes are pre-built connectors that provide ready-to-use actions for common integration scenarios. FSO and the broader ServiceNow ecosystem offer spokes for core banking systems, card processors, payment networks, and other financial services platforms. Using spokes accelerates implementation, reduces custom development, and ensures supportability.

Learn more: Integrating with spokes

Custom Integrations

When pre-built spokes are not available for your core banking system or external service, ServiceNow provides several options for building custom integrations:

• REST Message — For REST API calls to external systems. Configure HTTP methods, authentication, headers, and request/response handling to connect to modern APIs.
• SOAP Message — For SOAP-based web services. Some legacy banking systems expose SOAP APIs, and ServiceNow's SOAP Message framework supports WSDL import and message configuration.
• Integration Hub Custom Actions — Build your own reusable actions in Flow Designer. Custom actions encapsulate integration logic and can be reused across multiple flows and subflows.
• MID Server — The recommended path for integrating with systems behind a client's firewall. Many banks run on-premise core banking systems that cannot be reached directly from the ServiceNow cloud. The MID Server is installed within the bank's network and acts as a secure proxy, enabling ServiceNow to communicate with internal systems without exposing them to the internet. This is a critical component for most banking FSO implementations.
• Import Sets and Scheduled Jobs — For batch data imports. Use scheduled jobs to pull data from external systems via file or API on a recurring basis. Ideal for master data synchronization (customers, accounts, products).
• Scripted REST APIs — For inbound integrations where external systems push data to ServiceNow. Create custom endpoints that external systems can call to create or update records in FSO.

Learn More: REST API Reference | SOAP Web Service | Building integrations in Integration Hub | MID Server | Import Sets | Scripted Rest APIs

Remote Tables

Remote Tables provide a powerful mechanism for accessing external data without persisting it in ServiceNow. The external data lives in memory in read-only mode, making it temporary (transient) within the platform. This is ideal for data that changes frequently, data with storage restrictions, or scenarios where persistence is unnecessary.

How Remote Tables Work:

• A Remote Table definition creates a table schema in ServiceNow (columns, types)
• An associated script or Flow Designer flow executes when the table is accessed
• The script calls an external API and populates the table with returned data
• Data lives in memory only — it is not persisted to the database
• Caching (configurable TTL) reduces API calls for repeated access within the cache window

Key configuration options include Cache TTL (how long data remains valid in memory), Cache by User (whether each user gets their own cached copy), and Extended Capacity for larger datasets. FSO provides pre-built remote table structures for common banking data through the Financial Services Remote Tables plugin.

Learn more: Remote Data Options for Remote Tables

FSO Remote Tables Plugin

FSO includes a dedicated plugin called Financial Services Remote Tables [sn_bom_remote] which provides the framework for remote table integration. A key capability of this plugin is supporting data persistence between remote tables and local tables. When you need to save data from a remote table to a local FSO table, the plugin ensures a 1:1 copy of the schema, making it straightforward to persist selected records. This is essential for scenarios like disputes where you display many transactions via remote table but only persist the specific transactions being disputed.

Learn more: Components Installed with Financial Services Remote Tables

Lookup & Save with FSO Lookup Client Action

One of the most common integration patterns in FSO is "Lookup & Save" — querying an external system, caching the results in memory, and then selectively persisting only the data that needs to be stored in ServiceNow. FSO provides the FSO Lookup Client Action to streamline this pattern.

The FSO Lookup Client Action caches data in memory from a core banking or external system, allowing agents to view and interact with external data without immediately persisting it. When the agent identifies specific records that need to be retained (for case context, audit trail, or workflow processing), those selected records are then saved to local FSO tables.

Example — Loan Deferment: When an agent opens a Loan Servicing case, they need to see all loans tied to the customer to identify which one requires a deferment. The FSO Lookup Client Action helps retrieve all loan accounts for the customer from the core banking system and displays them to the agent in ServiceNow. The agent selects the specific loan requiring deferment, and only that loan is persisted to the Loan Account table in ServiceNow. This approach avoids storing unnecessary loan data for the customer while ensuring the loan that requires deferment is captured properly for servicing workflows and compliance tracking.

Learn more: FSO Look Up Client action

What's Next

With your data model foundations in place, you are ready to begin configuring FSO applications. Explore these related resources:

• Financial Services Operations (FSO) for Banking: Application Overview — Deep dive into each FSO banking application
• Building Custom Banking Applications — Best practices for extending FSO (Coming Soon)
• FSO Solution Design Assessment — Framework for evaluating implementation readiness (Coming Soon)

Get Involved:

• Subscribe for updates on the FSO Community Forum
• Review videos on our Financial Services Operations YouTube Playlist

Happy implementing! Comment below for questions, additional assets, or to share your Banking Data Model success stories.

Labels: Financial Services Operations, Banking, FSO, Implementation, Data Model, Integration