Skip to content
NexusBook a demo

Financial services use case · Stripe + ServiceNow + OpenAI + Snowflake

Payment hold review and release

A payment rule applies a hold, but the context needed to resolve it is assembled separately from the payment-control record. A held payment reaches a named reviewer with its rule trigger, recent activity and a recorded release or confirmation decision.

Discuss this use case Financial services overview

Systems involved

What each system contributes

Stripe

43 actions

  • Core Resources16
  • Billing19

Trigger source: Stripe

ServiceNow

55 actions

  • Tickets10
  • Incidents12

Trigger source: ServiceNow

OpenAI

25 actions

  • Chat Completions8
Snowflake

35 actions

  • Tables6
  • Views6

The hold mechanism depends on the institution's actual payment-control system and its supported interface; Stripe supplies the relevant available transaction context or permitted operation. 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

Trigger: payment-control interfaceSystem Action: ServiceNowIntegration: Stripe + SnowflakeAI step: model of your choiceHuman ApprovalInterface: payment controlAudit

How it starts: A payment velocity or risk rule applies a hold through the institution's authorized payment-control interface under policy.

Step by step

How the process runs

  1. 01

    Capture the hold

    Record the payment reference, rule version and confirmed hold state in ServiceNow, reading relevant Stripe activity where it is part of the payment path.

  2. 02

    Enrich the case

    Gather permitted recent transaction and account context from Snowflake and the approved payment or core-system interfaces.

  3. 03

    Summarize the behaviour

    The selected model describes the account's recent activity and explains how the held payment differs from that context, citing the supporting records.

  4. 04

    Obtain the reviewer decision

    Present the rule trigger, source evidence and model summary to the named reviewer for a release, confirmation or escalation decision.

  5. 05

    Apply and verify

    A separate payment-interface action executes the authorized decision, checks the resulting payment state and updates the linked review case.

Control

Human decision and exception path

Human decision

The named reviewer approves release or confirmation of the hold, with any additional authority required by the institution's policy. The automatic hold comes from the configured deterministic rule, while the model contributes context without releasing or confirming it.

Exception path

  • An unconfirmed hold state is investigated through the payment interface before the case is treated as a successful hold.
  • Missing account history or changed payment status returns the case to the reviewer with the current evidence.
  • An uncertain release response is reconciled against the authoritative payment state before retry or closure.

Evidence

What gets audited

  • Payment reference, triggering rule and original hold confirmation.
  • Enrichment sources and model behaviour summary.
  • Named reviewer decision, authority and timestamp.
  • Release or confirmation request and verified destination state.

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 deployment

Related

Patterns, connectors and next steps

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?
A payment velocity or risk rule applies a hold through the institution's authorized payment-control interface under policy.
What if a step is not covered by a pre-built action?
The hold mechanism depends on the institution's actual payment-control system and its supported interface; Stripe supplies the relevant available transaction context or permitted operation. 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.
Can the model release a payment when its summary supports release?
No; only the named reviewer's authorized decision releases the separate payment action.

Use case review

Discuss this use case

Bring your version of the process. We will map the systems, approvals and evidence it needs.

Discuss this use case Book a demo