Evaluate Fidren beside what you do today, before it can change anything.
Call Fidren before a transaction, record the answer, and do not let that answer change execution yet. That is the whole of it — not a mode Fidren runs, a posture you choose.
The decisions are real Fidren decisions, produced the same way they always are. What changes is what your system does with them.
A way to integrate without delegating enforcement yet.
- Observe how Fidren answers your real requests
- Compare those answers with your existing policy or workflow
- Understand operational fit before anything depends on it
- Inspect the cases that produce REVIEW, ALLOW_WITH_LIMIT, ALLOW_WITH_ESCROW or BLOCK
- Integrate the API without immediately gating a payment on it
This page makes no claim about measured accuracy, savings or fraud reduction. Fidren is early, and none of that has been measured.
One decision path. The fork is after it, and it is yours.
Fidren produces one decision. Your code decides what to do with it.
The three steps below happen identically whether you are observing or enforcing. Nothing is shortened, skipped or answered by a second, lighter engine because you are only watching.
- 1 · Your agent calls Fidren The same authenticated Decision API call documented on Developers, before the payment is made.
- 2 · Fidren evaluates in full The same five stages, the same record, the same scoring. Nothing is skipped because the caller is only observing.
-
3 · Fidren returns a decision
One of the five actions, with
recommended_limit_cents,confidenceand the rest of the response — the same shape either way.
The fork happens here, after the decision comes back — never inside Fidren, and never before step 3.
Log the answer. Existing behaviour stays authoritative.
Your code records the decision beside the transaction it would have made anyway, and proceeds exactly as it does today. Nothing Fidren returns changes what happens next.
A complete decision, produced the same way. Not yet acted on.
Apply the answer through your own transaction policy.
Your code chooses to let the decision gate execution — capping a payment at the recommended limit, holding it for a person on REVIEW, or declining it on BLOCK. Fidren still does not execute, hold or sign anything; your infrastructure acts.
The same decision, now acted on by code you control.
Later outcome reporting is independent of this fork — more on that below.
Everything Fidren does.
- The same Decision API — one authenticated call
- The same risk engine, record and requested exposure
- The same five actions, confidence and recommended-limit behaviour
Only what your code does after the call.
Shadow — your code logs the decision; existing execution behaviour stays authoritative. Enforcing — your transaction policy acts on the answer. Either way, Fidren itself never switches enforcement on: it never had the ability to.
Every row describes the customer's side of the call, not Fidren's.
| Shadow / observe | Enforcing | |
|---|---|---|
| Decision evaluation | Full, every stage | Full, every stage |
| Decision returned | Same five actions, same fields | Same five actions, same fields |
| Customer logs the result | Typically, to compare | Optional — a customer may or may not |
| Customer transaction behaviour changes | No — existing behaviour is authoritative | Yes — the decision gates it |
| Outcome reporting available | Independent of posture | Independent of posture |
Every step here is something you decide. Fidren does not promote an integration from shadow to enforcing on its own.
A sensible progression, entirely in your hands.
- Integrate the Decision API documented on Developers.
- Observe decisions beside your current workflow, without gating anything on them.
- Review mismatches and operational fit: the REVIEW, LIMIT, ESCROW and BLOCK cases especially.
- Decide, on your side, whether and how to enforce individual decision classes.
Only fields the API actually returns. The full response is documented on Developers.
What a shadow integration has to compare with.
- decision
- Which of the five actions this record and this amount produced.
- confidence
- How much of the record the answer rests on — worth comparing against how confident your own workflow felt.
- recommended_limit_cents
- The ceiling the record supports, whether or not you act on it yet.
- trust_score
- Context for the decision, not the action to compare against — read alongside
decision, never in place of it. - x-request-id
- Response header that correlates this call with your own logs — not a body field on a successful call.
- Your own workflow outcome
- Whatever your existing process already produces — not something Fidren tracks for you.
There is no shadow=true parameter, no
dry-run endpoint and no alternate scoring mode. Every call to
POST /v1/decision is the same call.
Whether the response affects execution belongs entirely to the
caller, not to anything Fidren is told.
Later reports do not depend on which posture produced the decision.
A party reporting how an operation went can contribute to the record regardless of whether the original decision was observed or enforced. Reporting does not happen automatically, and nothing on this site describes an outcome as verified — a stored report is an attributed statement, as Security explains.
The trust boundary is on Security.
Enforcing changes nothing about custody. Fidren still does not hold funds, hold keys, sign, execute or settle a transaction — under either posture. "Enforcement" means your own infrastructure acting on the decision it received; Fidren's role stops at the answer.
Fidren is early and is looking for design partners. Commercial pricing is not published yet.
Run it beside a real workflow.
The clearest way to evaluate Shadow Mode is against a transaction flow you already have. If you have one, we would like to hear about it.