Automated Fraud Decisioning: Allow, Challenge, Block

Decisioning is the process of converting a raw risk score and your configured business rules into a concrete action your application can execute. Rather than leaving your team to manually interpret scores and decide what to do, FraudEG’s decisioning engine evaluates every transaction against your rule set and returns a single decision field in the API response — allow, challenge, or block — so your application can branch immediately without additional logic.

Decision Outcomes

Every transaction response includes a decision field with one of three values:

`allow`

The transaction passes your risk thresholds and rule conditions. Proceed normally — fulfill the order, log the user in, or complete the transfer. No additional verification is required unless your application has independent requirements.

`challenge`

The transaction falls in a risk band that requires additional user verification before proceeding. FraudEG returns a recommended_action field alongside challenge to indicate the verification method most appropriate for the risk level — for example, 3ds_challenge, sms_otp, or email_confirmation. Your application is responsible for initiating the challenge and reporting the outcome.

`block`

The transaction exceeds your configured risk thresholds or matches a block rule. Reject the transaction immediately and do not fulfill it. Return an appropriate error to your user. FraudEG logs the block event and includes the contributing signals in the response for your records.

Consuming the `decision` Field

The decision field appears at the top level of every /v1/transactions/score and /v1/transactions/evaluate response. Read it before taking any action on the transaction.

Receive the API response

Call POST /v1/transactions/score with your transaction payload. FraudEG returns the score, signals, and decision synchronously in the response body.

Read the `decision` field

Extract the decision value from the response. This is your authoritative action directive — your downstream logic should branch exclusively on this field, not the raw score.

Handle `allow`

Proceed with the transaction normally. Optionally log the transaction_id, score, and signals for reporting and model feedback.

Handle `challenge`

Initiate the step-up verification method indicated in recommended_action. After the user completes the challenge, report the outcome back to FraudEG using POST /v1/decisions/{transaction_id}/outcome so the result is factored into future scoring.

Handle `block`

Reject the transaction. Return a user-facing error message. Do not expose the internal reason for the block. Record the transaction_id and signals for your fraud operations team.

Node.js Example

const response = await fraudeg.transactions.score({
  user_id: "usr_8f3k2p",
  amount: 349.00,
  currency: "USD",
  payment_method: { type: "card", token: "tok_visa_xxxx4242" },
  session_id: "sess_7Tz3mKpR9vLq",
});

const { decision, recommended_action, transaction_id, signals } = response;

switch (decision) {
  case "allow":
    await fulfillOrder(transaction_id);
    break;

  case "challenge":
    if (recommended_action === "3ds_challenge") {
      await initiate3DS(transaction_id);
    } else if (recommended_action === "sms_otp") {
      await sendSMSOTP(transaction_id);
    }
    break;

  case "block":
    logger.warn("Transaction blocked", { transaction_id, signals });
    throw new PaymentDeclinedError("Your transaction could not be completed.");

  default:
    throw new Error(`Unexpected decision: ${decision}`);
}

Decision Overrides

You can programmatically override a decision — for example, after a fraud analyst reviews a transaction in your queue — using POST /v1/decisions.

curl -X POST https://api.fraudeg.com/v1/decisions \
  -H "Authorization: Bearer feg_live_sk_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_4kR9mXpL2vQw",
    "override_decision": "allow",
    "reason": "manual_review_cleared",
    "analyst_id": "analyst_jsmith"
  }'

Overrides are recorded in the audit log with the analyst ID and reason, and they contribute to model feedback to improve future scoring accuracy.

Configuring Rules in the Platform

The no-code rule builder in Platform → Risk Rules lets you define exactly how scores and signals map to decisions for your specific business context. You can:

Set score-band thresholds per decision outcome.
Add signal-based conditions (e.g., always block when bot_detected is present).
Scope rules to specific flows — checkout, login, onboarding, or high-value transfers.
Set rule priority to control evaluation order when multiple rules match.
A/B test rule configurations against live traffic before fully rolling them out.

All rule changes are versioned and take effect within seconds of saving.

Real-Time vs. Asynchronous Decisioning

Mode	Latency	Use Case
Real-time	<100ms (p99)	Checkout, login, onboarding — any flow requiring an immediate response
Asynchronous	Seconds to minutes	High-risk transactions routed to a manual review queue; batch re-scoring

In asynchronous mode, the initial API response returns decision: "pending" with a review_id. FraudEG sends the final decision to your configured webhook once review is complete.

Use automatic decisions (real-time mode) for the vast majority of your transaction volume — they handle low and very-high risk transactions instantly. Reserve manual review queues for the medium-risk band where human judgment adds the most value. This keeps your operations team focused and avoids review queue overload.

Get Started

Core Concepts

Guides

Platform

Automated Fraud Decisioning: Allow, Challenge, Block

Decision Outcomes

`allow`

`challenge`

`block`

Consuming the `decision` Field

Node.js Example

Decision Overrides

Configuring Rules in the Platform

Real-Time vs. Asynchronous Decisioning

​Decision Outcomes

​allow

​challenge

​block

​Consuming the decision Field

​Node.js Example

​Decision Overrides

​Configuring Rules in the Platform

​Real-Time vs. Asynchronous Decisioning

Decision Outcomes

`allow`

`challenge`

`block`

Consuming the `decision` Field

Node.js Example

Decision Overrides

Configuring Rules in the Platform

Real-Time vs. Asynchronous Decisioning