ormuz
Accueil/Intégrations/Sumsub/Nodes/Evaluate transaction (Sumsub)
SumsubRouteurBeta

Evaluate transaction (Sumsub)

Soumet une transaction à Sumsub Transaction Monitoring et retourne une décision opérationnelle de routage, sans créer d’objet métier Ormuz.

Vue d’ensemble

Objectif

Ce node est un gate de décision pour un checkout, un payout ou un transfert. Il ne produit ni compliance_check, ni risk_score, ni draft à persister.

Le node pousse la transaction au KYT Sumsub, lit la décision immédiate quand elle existe, et suspend le process uniquement si Sumsub met la transaction en revue.

transaction_evaluation est la sortie métier principale : elle porte la décision, le score, les règles déclenchées et la réponse provider brute.

Le node route directement sur transaction_evaluation.decision avec les branches approved, rejected, review_required et awaiting_user.

awaiting_user n’embarque pas d’expérience hébergée dans ce node : le processus peut brancher ensuite un node dédié, par exemple sumsub.step_up_liveness.

Quand l’utiliser

  • Vous voulez bloquer ou autoriser une transaction pendant un parcours de checkout ou de payout.
  • Vous voulez soumettre une transaction à des règles fraude, AML transactionnelle ou monitoring Sumsub sans créer un résultat de conformité par transaction.
  • Vous voulez gérer les cas de revue manuelle avec une attente provider encapsulée dans le même node.

Paramètres 6

extension_config_idRequisref(extension_config:sumsub)
Configuration provider Sumsub active utilisée pour signer l’appel KYT.
subjectRequisContact
Porteur Ormuz de la transaction. Le node accepte une contact ou une company déjà mappée à un applicant Sumsub.
transactionRequisobject
Payload transactionnel envoyé à Sumsub selon le contrat KYT Sumsub (txnId, txnDate, type, info, applicant, counterparty, etc.).
sumsub_applicantOptionnelSumsub applicant
Applicant Sumsub à utiliser si le processus le possède déjà. Sinon le node le retrouve via le mapping du sujet.
payment / psp_payment / supplier_paymentOptionnelobject
Objet métier Ormuz lié au contexte de décision. Il n’est pas persistant en sortie du node ; le process décide lui-même quoi faire sur chaque branche.
device_access_token / session_id / device_contextOptionnelobject
Contexte Device Intelligence à joindre à une transaction financière. La collecte se fait côté client avec le SDK fisherman ; le node transaction reste le point d’entrée pour les événements financiers.

Sorties 3

sumsub_transactionSumsub transaction
Transaction KYT Sumsub normalisée, corrélée par id / transaction_id au kytTxnId.
transaction_evaluationSumsub transaction evaluation
Résultat métier provider-native de l’évaluation transactionnelle. Il porte decision, score, triggered_rules, review_answer, review_status et raw_response.
selected_routeenum
Route sélectionnée par le node, dérivée de transaction_evaluation.decision.

Comportement

Soumettre la transaction

Le node retrouve l’applicant Sumsub lié au sujet Ormuz puis appelle l’endpoint KYT de soumission transactionnelle.

Router la décision immédiate

Si Sumsub retourne une décision finale, le node se termine avec selected_route: approved ou selected_route: rejected.

Attendre seulement la revue

Si Sumsub place la transaction en revue, le node suspend le process sur extension.sumsub.applicant_kyt_txn_reviewed, corrélé par kytTxnId.

Exemple de processus

Objet métier + Transaction
Évaluer une transaction (Sumsub)
Approuvé
Rejeté
Revue requise
Action utilisateur requise

Transaction Monitoring est une décision opérationnelle sur une transaction, pas une preuve de conformité persistée.