Skip to main content
For organization_type = banco: you operate core banking, switches, or treasury platforms. You typically integrate pay-in assess (when applicable) and payout assess before disbursements, plus institutional modules (cases, fraud network).

​
Modules you need

ModuleRequired?Guide
Payout assessYes (dispersions)Payout assessment
Prevention — pay-in assessIf card/rails APIReal-time assessment
API keysYesAPI keys
Blocklists (flow_scope)Yes for payoutBlocklists
Outbound webhooksRecommendedReceiving webhooks
Assess resilienceYes (prod)Assess resilience
Cases & regulatoryYes (CLM-MOD-OPS)Case management
Report fraudYesReport fraud
Fraud intelligence networkIf contractedDashboard → Inteligencia
Event ingestionOptionalEvent ingestion
Browser SDKRareUsually N/A for core banking

​
Integration phases

1

Phase 1 — Core & keys

  1. Confirm SQL migrations for payout (079 blocklists flow_scope, 080 assess_flow) with your Clausum team.
  2. Conexiones → Claves API — Secret keys (clm_sk_*) from core middleware only — never in channels.
  3. Document fail-open policy — Assess resilience.
2

Phase 2 — Payout prevention (primary)

Call assess before SPEI, wire, or internal transfer authorization:
{
  "amount": 25000.00,
  "amount_unit": "major",
  "currency": "MXN",
  "beneficiary": {
    "id": "ben_core_001",
    "name": "Beneficiary SA",
    "country": "MX",
    "clabe": "012180001234567890"
  },
  "origin": { "account_id": "acct_orig_01", "country": "MX" },
  "payout": {
    "channel": "spei",
    "initiated_by": "ops@bank.com",
    "first_to_beneficiary": false
  }
}
  1. POST /api/v1/assess/payout with clm_sk_*.
  2. On decline → do not release funds; log session_id on the transfer record.
  3. Load CLABE/IBAN blocklists with flow_scope: payout — Blocklists.
  4. Test via POST /api/v1/simulation/payout in Dashboard.
Full playbook: Payout assessment.
3

Phase 3 — Pay-in (if applicable)

When your API exposes card or instant-payment acceptance:
  • POST /api/v1/assess with payment_id, customer_id as core references
  • order_id usually N/A outside e-commerce
  • Live fields: GET /api/v1/assess → field_requirements_by_segment.bank
4

Phase 4 — Webhooks & core reconciliation

  1. Outbound URL for transaction.created, transaction.blocked, case.created.
  2. Map session_id to core transaction ids.
  3. Optional ingest for switch events — Event ingestion.
5

Phase 5 — Operations & network

  1. Case management for expedientes and regulatory submission.
  2. Report fraud feeds blocklists automatically.
  3. If CLM-MOD-INST / network add-on: configure contribute/consume in Configuración → Empresa → Red de inteligencia.
  4. UAT on cert.clausum.ai when provided for sign-off.

​
Required assess fields

​
Pay-in (POST /api/v1/assess)

FieldLevel
amount, currencyRequired
payment_idRecommended — core / switch reference
customer_idRecommended — account or party id
order_idOptional

​
Payout (POST /api/v1/assess/payout)

FieldLevel
amount, currencyRequired
beneficiaryRequired — country, name, clabe, iban, or account_hash
origin.account_id, origin.countryRecommended
payout.channelRecommended — spei, wire, api
Live catalog: GET /api/v1/assess/payout.

​
Payout signals to expect

SignalTypical trigger
payout_first_beneficiaryFirst transfer to beneficiary
payout_high_risk_countryBeneficiary jurisdiction
payout_cross_border_high_amountCross-border above threshold
Blocklist hitCLABE / IBAN / beneficiary_id

​
Go-live checklist

  • Migrations 079 + 080 applied in production Supabase
  • Payout blocklists loaded with correct flow_scope
  • Core calls assess synchronously before transfer release
  • 503 / 504 fallback approved by risk committee
  • Cases workflow and roles configured
  • Certification UAT completed on assigned stage host

Payout assess

Disbursement API

Blocklists

flow_scope and payout types

Cases

Expedientes

All capabilities

Module catalog