Polaris
The compliance layer for financial and on-chain transactions.
Polaris decides whether a transaction should be allowed — before execution.
Run AML, jurisdiction, and policy checks in real time.
Return clear verdicts, reason codes, and audit traces.
Key principle
Polaris sits before execution — not after.
Every transaction is evaluated before it happens.
Why Polaris
Today, compliance is:
- Manual and slow
- Inconsistent across systems
- Disconnected from execution
As financial systems and tokenized assets scale, every transaction needs a deterministic decision before execution.
Polaris moves compliance from:
after-the-fact checks → real-time decisioning
How Polaris Works
Polaris sits before execution.
- 1
Your system creates a transaction
- 2
Calls Polaris
- 3
Polaris evaluates against a policy
- 4
Returns verdict (allow / block / review), reason codes, and evaluation trace
- 5
Your system executes or blocks
Polaris does NOT custody funds.
Polaris does NOT execute transactions.
It is a decision layer.
Quickstart
POST /evaluate-transaction with from, to, amount_wei, policy_id.
Decision Output
Every evaluation returns a structured decision: verdict, reason codes, risk summary, and evaluation trace for audit.
Verdict
- ALLOWED
- BLOCKED
- REVIEW
Reason codes
- RC_101 — Recipient not approved
- RC_203 — Jurisdiction restriction
Evaluation trace
Step-by-step rule execution for audit and compliance.
Use Cases
Polaris is used by:
- Crypto exchanges → pre-trade AML checks
- Token issuers → enforce transfer restrictions
- Fintech platforms → compliance before payments
- Custodians → policy enforcement layer
Example reason codes
Stable, integration-ready identifiers for custody, transfer-agent, and chain layers.
- RC_001 — sender_blacklisted
- RC_002 — recipient_not_whitelisted
- RC_003 — account_frozen
- RC_004 — insufficient_unlocked_balance
No custody · No execution · No risk
- Polaris never touches assets or keys — evaluation is fully off-chain.
- No transactions are submitted from this product tier.
- API-first verdicts for issuance, transfer-agent, and custodian workflows.
Policies
A policy defines how transactions are evaluated — versioned, reusable, and configurable via API or workspace. Read more in Docs.
API
Designed for real-time pre-trade checks in production systems.
Endpoints
POST /evaluate-transaction
POST /evaluate-batch
Request: from, to, amount_wei, policy_id. Response includes verdict (allowed), reason_code_ref, detail, evaluation_trace.
POST /evaluate-transaction
Content-Type: application/json
{
"from": "0x…",
"to": "0x…",
"amount_wei": "1000000000000000000",
"policy_id": "mica_default_v1"
}{
"verdict": "BLOCKED",
"reason_codes": ["RC_101"],
"message": "Recipient not in approved registry",
"evaluation_trace": [...]
}Live responses use allowed, reason_code_ref, and detail; map to verdict / reason_codes / message in your integration layer.
Key principle
Polaris sits before execution — not after.
Every transaction is evaluated before it happens.
Run a pre-trade check