Domain Separation e Financial Services Payment Operations

  • Versão de lançamento: Zurich
  • Atualizado 31 de jul. de 2025
  • 3 min. de leitura
  • A separação de domínio é compatível com Financial Services Payment Operations. O Domain Separation permite separar dados, processos e tarefas administrativas em agrupamentos lógicos chamados de domínios. Você pode controlar vários aspectos dessa separação, incluindo quais usuários podem ver e acessar os dados.

    Nível de suporte: Básico

    • Lógica de negócios: confirme se os dados vão para o domínio adequado para os casos de uso do provedor de serviço de aplicativo.
    • O aplicativo oferece suporte à separação de domínio em tempo de execução. O Domain Separation inclui separação de domínio de interface do usuário, chaves de cache, emissão de relatórios, acúmulos e agregações.
    • O proprietário da instância deve configurar o aplicativo para funcionar em vários locatários.

    Exemplo de caso de uso: quando um SP (service provider, provedor de serviço) usa o bate-papo para responder à mensagem de um locatário-cliente, o cliente deve conseguir ver a resposta do SP.

    Para obter mais informações sobre os níveis de suporte, consulte Suporte de aplicação para separação de domínio.

    Como o Domain Separation funciona no Financial Services Payment Operations

    Todos Operações de serviços financeiros (FSO) as aplicações são criadas em cima de Customer Service Management (CSM) e usar muitos CSM tabelas. As principais tabelas de referência são as tabelas do cliente, como Consumidor, Conta e Contato, e essas tabelas são separadas por domínio.

    Tabelas

    Todas as novas tabelas adicionadas em Operações de pagamento são separadas por domínio:
    • 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

    Casos de uso

    Consulta de pagamento
    Os clientes podem criar uma consulta de pagamento por meio do portal para os seguintes casos de uso:
    • Não recebimento de sinistro do beneficiário (BCNR): O cliente enviou um pagamento, mas o destinatário pretendido afirma nunca ter recebido o dinheiro.
    • Pagamento com erro (PIE) - O cliente comete um erro ao enviar um pagamento e está tentando recuperar o dinheiro.
    Os funcionários da filial e os agentes do call center podem criar essas consultas em nome do cliente. A equipe de Operações de pagamento recebe consultas de seus clientes, bem como de bancos externos.
    • As consultas internas vêm dos próprios clientes do banco. O cliente destinatário pode ser interno ou externo ao banco. A distinção entre destinatários internos ou externos é importante porque determina qual rota as Operações de pagamento seguem para resolver a consulta.
    • Consultas externas vêm de bancos terceirizados, o que significa que o destinatário do pagamento é sempre interno.
      Nota:
      Nunca pode haver um caso em que a consulta seja externa e o destinatário seja externo.
    • Algumas consultas podem resultar na criação de um sinistro.
    Sinistro de pagamento
    Os agentes de consulta podem criar um sinistro em nome de um cliente quando o banco determina que o sinistro é válido e o cliente tem direito a um reembolso.
    A equipe de Operações de pagamento recebe os sinistros internamente de uma consulta ou de um banco externo. Quando recebem o sinistro, começam a determinar onde obter o reembolso.
    • Os sinistros internos vêm de clientes do banco, seja de uma consulta ou diretamente da equipe do banco (agência ou call center). Os agentes podem resolver o sinistro se souberem onde obter o reembolso. O reembolso pode ser externo (pagamento a um cliente bancário terceirizado) ou interno (pagamento ao cliente do banco). Se o reembolso for interno, uma Aprovação de débito deverá ser criada (consulte Aprovação de débito abaixo).
    • Sinistros externos vêm de bancos terceirizados. O reembolso é sempre interno para sinistros externos. Os agentes podem precisar criar uma Aprovação de débito para reembolsos internos (consulte Aprovação de débito abaixo).
    Aprovação de débito
    Os agentes de sinistros criam aprovações de débito para que os clientes aprovem um reembolso de um sinistro. O cliente pode aceitar o débito, contestação ou rejeitá-lo.
    Nota:
    Às vezes, um ServiceNow® o recurso ou a aplicação da plataforma pode ser capaz de oferecer suporte eficaz a casos de uso do provedor de serviços, mesmo que a estrutura de domínio não esteja sendo usada. Nesse caso, a aplicação pode ser atribuída a Básico*, Padrão* ou Aprimorado* para seu nível de suporte de domínio e incluir casos de uso detalhados. Por exemplo: Antes da versão New York, Catálogo de serviços não tinha suporte a domínio. Mas o proprietário da instância conseguiu configurar catálogos e itens separados para cada cliente em uma instância separada por domínio. Isso permitiu que o Catálogo de serviços fosse usado em um Padrão nível de suporte. Para saber mais, consulte Separação de domínio Níveis de suporte da aplicação .