Domain separation and Financial Services Payment Operations

  • Release version: Zurich
  • Updated July 31, 2025
  • 3 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Domain separation and Financial Services Payment Operations

    Financial Services Payment Operations supports domain separation, enabling ServiceNow customers to segregate data, processes, and administrative tasks into logical domains. This separation controls user access and visibility, ensuring data integrity across multiple tenants or service providers. The application incorporates domain separation at runtime, affecting the user interface, cache keys, reporting, rollups, and aggregations.

    Show full answer Show less

    Instance owners are responsible for configuring the application to operate across multiple tenants, a critical capability for service providers managing communications and transactions between tenants and customers.

    Key Features

    • Domain-separated tables: All new tables in Payment Operations—such as payment inquiries, payment claims, payment services, and account types—are domain-separated to maintain data isolation.
    • Use cases supported:
      • Payment Inquiry: Customers and agents can create inquiries related to payment issues like Beneficiary Claim Non-Receipt or Payment in Error. These inquiries can originate internally (bank customers) or externally (third-party banks), with resolution paths varying accordingly.
      • Payment Claim: Agents can create claims when refunds are valid. Claims come internally from inquiries or directly from external banks. Refunds may be internal or external, with processes like Debit Approval applied as needed.
      • Debit Approval: Customers can approve, dispute, or reject refunds through created Debit Approvals, adding an additional control layer to refund processing.
    • Business logic support: Ensures data is assigned to the correct domain for service provider use cases, maintaining domain separation throughout all relevant operations.
    • Integration with Customer Service Management (CSM): Payment Operations is built on CSM, using domain-separated customer-related tables such as Consumer, Account, and Contact, ensuring consistent data segregation.

    Practical Implications for ServiceNow Customers

    By leveraging domain separation in Financial Services Payment Operations, ServiceNow customers—especially service providers—can:

    • Maintain strict data isolation between multiple tenants to meet governance and privacy requirements.
    • Control user access to data and processes across domains, enhancing security and operational clarity.
    • Handle payment inquiries and claims with confidence that data and processes belong to the correct domain.
    • Configure multi-tenant environments to support complex financial workflows involving both internal and external customers.

    This domain separation capability is provided at a basic support level for Payment Operations, ensuring foundational multi-tenant support with consistent user experience and data integrity.

    Domain separation is supported for Financial Services Payment Operations. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.

    Support level: Basic

    • Business logic: Ensure that data goes into the proper domain for the application’s service provider use cases.
    • The application supports domain separation at run time. The domain separation includes separation from the user interface, cache keys, reporting, rollups, and aggregations.
    • The owner of the instance must set up the application to function across multiple tenants.

    Sample use case: When a service provider (SP) uses chat to respond to a tenant-customer’s message, the customer must be able to see the SP's response.

    For more information on support levels, see Application support for domain separation.

    How domain separation works in Financial Services Payment Operations

    All Financial Services Operations (FSO) applications are built on top of Customer Service Management (CSM) and use many CSM tables. The key reference tables are the customer tables such as Consumer, Account, and Contact, and these tables are domain-separated.

    Tables

    All new tables added in Payment Operations are domain-separated:
    • sn_bom_payment_inquiry
    • sn_bom_payment_inquiry_task
    • sn_bom_payment_service
    • sn_bom_payment_claim
    • sn_bom_payment_claim_task
    • sn_bom_checking_account
    • sn_bom_saving_account

    Use cases

    Payment Inquiry
    Customers have the ability create a payment inquiry via the portal for the following use cases:
    • Beneficiary Claim Non-Receipt (BCNR): The customer has sent a payment, but the intended recipient claims to have never received the money.
    • Payment in Error (PiE) – The customer makes a mistake when sending a payment and is trying to retrieve the money.
    Branch workers and call center agents can create these inquiries on behalf of the customer. Payment Operations staff receive inquiries from their customers as well as from external banks.
    • Internal inquiries come from the bank’s own customers. The recipient customer could be internal or external to the bank. The distinction between internal or external recipients is important because it determines which route Payment Operations takes to resolve the inquiry.
    • External inquiries come from third-party banks, which means that the payment recipient is always internal.
      Note:
      There can never be a case where the inquiry is external and the recipient is external.
    • Some inquiries may result in the creation of a claim.
    Payment Claim
    Inquiry agents can create a claim on behalf of a customer when the bank determines that the claim is valid and the customer is entitled to a refund.
    Payment Operations staff receive the claims either internally from an inquiry or from an external bank. When they receive the claim, they start determining where to get the refund.
    • Internal claims come from customers of the bank either from an inquiry or directly from bank staff (Branch or Call Center). Agents can resolve the claim if they know where to get the refund. The refund could be either external (payment to a third-party bank customer) or internal (payment to the bank's customer). If the refund is internal, a Debit Approval must be created (see Debit Approval below).
    • External claims come from third-party banks. The refund is always internal for external claims. Agents may need to create a Debit Approval for internal refunds (see Debit Approval below).
    Debit Approval
    Claim agents create Debit Approvals for customers to approve a refund from a claim. The customer can either accept the debit or dispute or reject it.
    Note:
    Sometimes a ServiceNow® platform feature or application may be able to effectively support service provider use cases even though the domain framework is not being used. In this case, the application may be assigned Basic*, Standard*, or Enhanced* for its domain support level, and include detailed use cases. For example: Before the New York release, Service Catalog had no domain support. But the instance owner was able to configure separate catalogs and items for each customer in a domain-separated instance. This allowed Service Catalog to be used at a Standard support level. To learn more, see domain separation Application levels of support.