Assess fraud (SEON)
Assesses fraud risk for an order, checkout, payment, onboarding, or other business operation, then automatically routes the process to approval, manual review, or decline.
Vue d’ensemble
Assess fraud (SEON) assesses risk associated with one precise business action: account creation, sign-in, order, payment attempt, refund, or disbursement. The same company may therefore receive different decisions depending on the assessed action, timing, and available signals.
The subject is the anchor of the assessment. Use an order for an order, a checkout_session during checkout, or an onboarding_case during onboarding. Other parameters add company, person, and operation context.
- Data already present on Ormuz objects is used automatically when no explicit value overrides it.
- Email, phone, IP, device, amount, currency, and BIN signals enrich analysis but are not all mandatory.
- The SEON decision is normalized into an operational route; the process remains responsible for the final action.
Typical scenario
A buyer confirms a EUR 12,000 order. The process supplies the order as subject, the company as company, the contact as contact, plus the IP address and device session collected during checkout. SEON returns review_required: confirmation is suspended and the process opens a fraud review.
Quick start
Two bindings are enough to launch a first assessment. Then add available signals to improve decision quality.
Minimum requis
- Select an active SEON
extension_config_id. - Bind
subjectto the business object being assessed.
Recommended for checkout
- Choose a coherent
action_type, usuallypurchasefor an order. - Bind
companyandcontactto buyer context. - Pass the actually observed
ip_address. - Bind the output of
Collect device session (SEON)todevice_session.
| Parameter | Binding | Role |
|---|---|---|
subject | order | Assessed operation |
action_type | purchase | Decision context |
company | buyer_company | Buyer company |
contact | buyer_contact | Person initiating the action |
ip_address | checkout.ip_address | Actually observed IP |
device_session | collect_device.device_session | Recommended device signal |
amount, currency, email, or phone when they are already available on linked objects. Check Data resolution first.Decision routes
approvedAcceptable risk
SEON recommends continuing the operation.
review_requiredUncertain decision
Available signals are insufficient for a safe automatic approval or decline.
declinedHigh risk
SEON recommends not continuing the operation.
review_required, never to approved.Process example
Recommended checkout example: collect device signals, assess the order, then continue, request review, or block according to the SEON decision.
Data resolution
An explicitly configured node value always takes precedence. When absent, Ormuz looks for the data on linked business objects.
| Data | Priority order |
|---|---|
| Reference | transaction_reference → subject.id |
email → contact.email → subject.email | |
| Phone | phone → contact.phone → contact.phone_number → subject.phone |
| IP address | ip_address → subject.ip_address → subject.ip |
| Session appareil | device_session → subject.device_session |
| Amount | amount → subject.gross_amount → subject.amount → subject.amount_including_tax → subject.total_amount |
| Currency | currency → subject.currency |
| BIN | card_bin → subject.card_bin |
| User identity | contact → company |
Parameters 15
Essentiels
Parameters required to obtain a usable decision.
platform.company, platform.contact, platform.onboarding_case, platform.checkout_session, platform.order, platform.invoice, and platform.supplier_invoice. Its identifier becomes the default SEON reference. Depending on the object, the node may also reuse available amount, currency, email, phone, IP address, or BIN.purchase.| Value | Cas d’usage |
|---|---|
signup | Account creation |
login | Connexion |
account_update | Sensitive account modification |
checkout | Order journey |
purchase | Purchase or order confirmation |
payment_attempt | Payment attempt |
payment | Completed payment |
refund | Remboursement |
payout | Disbursement or outgoing transfer |
custom | Specific business event |
Contexte client
Information about the company or person behind the operation.
contact.email, then subject.email. Returned enrichment depends on Email Intelligence being enabled on the configuration and SEON account.contact.phone, contact.phone_number, then subject.phone. Prefer an international E.164 number, for example +33612345678.Operation context
Economic value and reference of the assessed event.
subject.gross_amount, subject.amount, subject.amount_including_tax, then subject.total_amount. The value is sent as-is: use an amount convention consistent with your Ormuz objects and SEON contract.EUR, USD, or GBP. When absent, the node uses subject.currency. The value is normalized to uppercase.subject identifier. Set it when several distinct assessments must exist for the same object, for example ord_123:payment_attempt:2. The node fails when no reference can be determined.Signaux antifraude
Network, device, and card signals that improve scoring quality.
subject.ip_address, then subject.ip. It enables geolocation, proxy, VPN, Tor, datacenter, and reputation signals available from SEON.Collect device session (SEON). Bind its device_session output here to enrich the assessment with Device Intelligence. The content remains opaque to the process and may be omitted when no device collection is available.Advanced settings
Use these parameters to adjust enrichments or send controlled metadata to SEON.
| Property | Effet |
|---|---|
email_api | Email-address analysis and enrichment |
phone_api | Phone analysis and enrichment |
ip_api | Network, location, and IP-reputation analysis |
device_fingerprinting | Use of the Device Intelligence session |
aml_api | AML enrichment when supported by your SEON plan |
sales_channel or customer_segment. Only keys present in custom_fields_allowlist on the SEON configuration are sent. Ormuz automatically adds ormuz_subject_type and ormuz_subject_id. Do not place secrets, full card numbers, or unnecessary personal data here.Outputs 9
Decision and traceability
Main outputs to use in the process.
fraud_assessment.decision determines the node route.approved, review_required, or declined.Get transaction (SEON) or for feedback.Enrichissements disponibles
Detailed signals present only when the corresponding modules are enabled and populated.
Binding compatibility
selected_value contains the same normalized decision as selected_route and serves bindings expecting a value rather than a route.
selected_route, available for bindings and process outputs.Behavior
Build the risk context
The subject sets the operation being analyzed. company and contact add company/person context, while explicit values override automatically derived data.
Apply enrichments
Email, Phone, IP, and Device modules follow SEON configuration settings unless temporarily overridden through modules. AML is disabled by default.
Assess and normalize
SEON analyzes available signals. Ormuz exposes the provider transaction, normalized assessment, and available enrichments without modifying the assessed business object.
Select the route
Approval states become approved, decline states declined, and review, intermediate, or unknown states review_required.
Reuse the result
When the subject has an identifier, Get transaction (SEON) and Submit fraud feedback (SEON) can resolve the transaction from that same subject.
Limits and responsibilities
- The node does not collect device signals itself: use
Collect device session (SEON)when Device Intelligence is required. - It does not modify the assessed order, customer, payment, or case and does not automatically create a risk business object.
approvedmeans risk is acceptable according to the received decision; it does not guarantee absence of fraud.declinedis a SEON operational recommendation. Process business policy determines the final action.- Human review or an additional check remains necessary when context, amount, or internal policy requires it.