A card program's exposure is no longer just fraudulent swipes — it is the mutation surface: agents and automated systems that create cards, raise limits, and lock merchants through your API. Your fraud stack scores what looks suspicious. Decionis governs whether the mutation is authorized to execute — ALLOW, ESCALATE, or BLOCK, decided against your policy before the action commits, with a signed Decision Dossier left behind it.
16,000+ approval gates already run through this decision layer in production — scoped here to the mutations a card program has to defend. It is built by a founder who spent two decades inside payment infrastructure: ISO 8583 switching at eTranzact, EMV instant issuance for tier-1 Nigerian banks at ExPad.
Card programs increasingly route consequential mutations through automated and agent-driven paths:
A model's recommendation — or an agent's API call — is not authority. Decionis verifies that the required approval level is present before the card is created, the limit is raised, or the lock is lifted.
When your compliance team, your bank partner's auditor, or a dispute asks “who authorized this and on what basis,” the answer is a signed chain of custody that existed at the moment of the decision — not a reconstructed log.
The hard part of governing a live card program is the boundary between risk scoring and execution authority — and proving it held. Decionis is designed to be pressure-tested on exactly that line.
Your fraud stack computes risk. Decionis evaluates whether this mutation, by this principal, under this policy version, is authorized to execute — and returns ALLOW, ESCALATE, or BLOCK before it commits. The two compose; neither replaces the other.
The gate evaluates the signals you choose to send — amount, merchant category, program state — never a stored PAN. On the wire-level roadmap the boundary is structural: raw frames, including PANs, stay inside your process.
The policy engine is stateless per request. A windowed rule — five card creates in an hour — needs a counter Decionis does not hold: you compute the counter, we enforce the rule against it. Roadmap work is labeled as roadmap, here and in the product.
Each workflow carries its honest posture label. Decionis starts where every primitive already exists — low-QPS card-lifecycle mutations with no cardholder data — and moves toward the authorization wire one scoped rollout at a time, starting from an offline replay.
Put a verdict in front of every card-lifecycle mutation your platform or your agents issue — create card, raise limit, merchant lock. Every primitive exists today: policy evaluation over the signals you supply, a signed Decision Dossier behind every decision, shadow mode first. Low QPS, no cardholder data — the gate sees the mutation request, never the PAN.
Mutation request → Decionis → ALLOW / ESCALATE / BLOCK → card action → Decision Dossier
Run the fintech sandbox packWhen policy says the cardholder must decide, the machinery is production-shaped: a push notification with Approve and Kill, a replay-bound execution grant — signed, 300 seconds by default, bound to the exact action so an ALLOW cannot be replayed against a different one — and a signed passport recording the outcome. Built and exercised behind our own consumer surface; pointing it at an issuer card program is integration work, not research.
Rollout component — Presence, the Human Approval Gate for an ESCALATE: it verifies the authorized person is really present on their own device and seals a signed Presence Record that Decionis re-checks before the action commits.
Sensitive action → Decionis → ESCALATE → push Approve / Kill → signed 300s grant → action commits → Decision Dossier
What Presence adds to an ESCALATEInline authorization decisioning over ISO 8583 is in private beta, not a shipped connector. The integration primitive exists: a TCP-level interceptor; your integration supplies field extraction (amount, PAN, MCC) via callback — raw frames, including PANs, stay in your process; an evaluation error tears down the connection. The boundary is the point — Decionis never holds cardholder data. Evaluation targets <120ms (p95, decision compute — a target, not an SLA). Issuer authorization-path SLAs are not claimed.
Auth message → interceptor → your field extraction → Decionis → forward / decline response / connection close → Decision Dossier
The same discipline the healthcare page applies to clinical claims applies here to payments claims: what does not exist is named as not existing.
The policy engine is stateless per request, so no windowed rule exists today. The interim contract is explicit: you compute the counter, we enforce the rule against it. Until a stateful engine ships, nothing on this page will imply otherwise.
None exist today. No vendor names and no logos appear here before a connector is real and its posture can be labeled honestly.
Policy evaluation runs over signals the caller supplies and does not require cardholder data; Decionis is not a PCI-assessed service provider.
Nothing is enforced before the evidence supports it — and nothing touches cardholder data before you decide it should. The lowest-risk phase comes first: your own historical logs, replayed offline, produce the prevented-fraud number before any integration work begins.
Replay your historical authorization logs through the policy graph, entirely offline. Deliverable: a shadow prevented-fraud report — what would have escalated or blocked, and why. No cardholder-data exposure, no PCI scope, nothing touches production.
Stand the interceptor in front of your processor simulator or sandbox. Prove the integration shape — the field-extraction callback, verdict handling, teardown on evaluation error — with zero live traffic.
Observe live authorizations on a narrow BIN range. Nothing is blocked; every observed decision produces a signed Decision Dossier, so the prevented-fraud report graduates from replayed history to live traffic.
Enable enforcement on that BIN range only. An ESCALATE resolves through the Human Approval Gate — Presence verifies the authorized person is really present on their own device and seals a signed Presence Record that Decionis re-checks before the action commits. A kill switch returns the scope to shadow instantly.
An approval log records that something called the API. A Decision Dossier records the authority behind it — designed as a legal instrument, cryptographically chained so it is tamper-evident, and verifiable without an account.
The category discipline is the point. Decionis governs execution authority, not risk scoring.
Start with an offline replay: your historical authorization logs, our policy graph, and a shadow prevented-fraud report — no cardholder-data exposure and no PCI scope.
