Financial services use case · ServiceNow + OpenAI + Snowflake + Salesforce
Sanctions and AML alert triage
Screening alerts require repeated collection of customer details, transaction context and prior review history before an analyst can assess the match. Analysts receive source-linked screening cases with a proposed disposition and the context needed to make their own decision.
Systems involved
What each system contributes
This workflow consumes the institution's screening vendor interface and coordinates the review; it does not imply a pre-built screening engine or connector. Core banking, lending, policy administration, claims, identity verification, KYC and sanctions screening have no pre-built Nexus connector. They are reached through the institution's approved APIs, database access or vendor interfaces, or as Rules + Code, inside the same workflow and with the same approvals and audit.
Architecture
One governed run
How it starts: An authorized sanctions or AML screening interface delivers a new alert or a material update to an existing alert.
Step by step
How the process runs
- 01
Register the alert
Capture the screening-provider reference, available match attributes and screening context in a restricted ServiceNow case.
- 02
Assemble the review context
Read permitted Salesforce customer details and Snowflake transaction or prior-disposition context, using approved core or screening interfaces for additional source evidence.
- 03
Compare the match
The selected model compares the alert attributes with the customer record and relevant prior decisions, explaining the evidence for a stronger or weaker association.
- 04
Prepare the analyst proposal
Present the model's proposed disposition alongside matched attributes, differences, screening references and any additional information needed.
- 05
Record the authorized outcome
After the named analyst decides, a separate ServiceNow or screening-interface step records the permitted disposition and any required escalation.
Control
Human decision and exception path
Human decision
A named sanctions or AML analyst decides the alert disposition under the institution's review policy. Any restriction, release, customer action or further escalation follows its designated authority; a model proposal does not close the alert or authorize the consequential action.
Exception path
- Missing identifiers or source records keep the case open for evidence collection.
- Changed screening data or a different customer context requires reassessment rather than automatic reuse of an earlier disposition.
- Repeated provider alerts are linked or routed under the configured case rules without silently discarding their evidence.
Evidence
What gets audited
- Screening alert, provider references and permitted source context.
- Customer comparisons, prior-disposition references and model proposal.
- Analyst decision, rationale and timestamp.
- Recorded disposition or escalation and destination responses.
Nexus runs on premises, in private or sovereign cloud, or air-gapped. Credentials stay in the vault, roles decide who can approve, and the execution record stays inside your deployment boundary.
Sovereignty and deploymentRelated
Patterns, connectors and next steps
- Snowflake-Salesforce integration
Integration pattern · CRM data feeds analysis, while selected analytical results return to Salesforce under explicit ownership rules.
- ServiceNow connector
55 pre-built actions
- OpenAI connector
25 pre-built actions
- Snowflake connector
35 pre-built actions
- Salesforce connector
73 pre-built actions
- Compliance evidence
Evidence produced by the work itself.
- Lead to account and ERP handoff
Another financial services use case.
FAQ
Questions about this use case
- Does Nexus replace any of these systems?
- No. Each system keeps its own records. Nexus runs the process between them and records each decision.
- How does the run start?
- An authorized sanctions or AML screening interface delivers a new alert or a material update to an existing alert.
- What if a step is not covered by a pre-built action?
- This workflow consumes the institution's screening vendor interface and coordinates the review; it does not imply a pre-built screening engine or connector. Core banking, lending, policy administration, claims, identity verification, KYC and sanctions screening have no pre-built Nexus connector. They are reached through the institution's approved APIs, database access or vendor interfaces, or as Rules + Code, inside the same workflow and with the same approvals and audit.
- Does a prior cleared alert automatically clear the next one?
- No; prior decisions provide review context, while the analyst evaluates the current alert and its applicable screening information.
Use case review
Discuss this use case
Bring your version of the process. We will map the systems, approvals and evidence it needs.