Pre-transaction Policy Controls

Your policy, checked before broadcast

Transactions routed through the controls are checked against your blocklists and chosen sources. Each decision is recorded with its reason.

Assess your signing flowA first conversation, with no commitment.

A module of Transaction Monitoring and Audit Evidence.

Capabilities

From signing to broadcast

Pre-transaction Policy Controls is a policy check on the signing and submission paths you route through it. Each transaction is checked against your blocklists and chosen sources before broadcast, receives an allow or block decision and is recorded with its rule, reason and timestamp. One rule set covers all your applications.

Applies to
Transactions routed through the controls
Rules
Your blocklists and chosen sources
Decision
Allow or block, before broadcast
Each decision
Recorded with its reason
Routed paths

Checks on the paths you route

Your signing and submission paths route through the controls, and each transaction on them is checked before broadcast. Contract call coverage is agreed in scoping.

Rules

One rule set across applications

Your blocklists and chosen sources define which destinations a transaction may reach. The same rules apply to every application on a routed path.

Decisions

A reason behind every allow or block

Allow and block results are stored with the matched rule, source and timestamp, so compliance can see why a transaction went through or stopped.

Outcome

What's included

Controls apply to transactions sent through the routed paths. Contract call coverage is agreed in scoping, and policy and sanctions decisions stay with you.

  • Blocked destinations stopped on routed paths
  • The same policy in every application
  • A stated reason behind every decision

Built on Archive RPC.

Support

Backed by agreed service levels

Service levels in writing

Uptime, response times and escalation paths are set in your agreement.

Support on your channels

Slack, Telegram or email, with hours that match your operations.

Monitored by engineers

Alerts reach our team before problems reach yours.

Questions

What teams usually ask us

Do pre-transaction controls stop transactions sent another way?

No. Checks apply to transactions routed through the controls. We map your signing and submission paths during scoping.

Do pre-transaction controls cover smart contract calls?

Coverage of contract calls is assessed per flow during scoping and listed in the proposal.

Who sets the pre-transaction policy rules?

Your team. Your blocklists and the sources you choose define each decision, and sanctions decisions stay with you.

Which networks can Pre-transaction Policy Controls support?

Any EVM network: L1s, L2s, appchains and custom chains, from private testnet to mainnet. Our public multichain explorer indexes 24 mainnet networks today, and we onboard new ones as part of setup.

Which screening and Travel Rule providers can we use with Routescan?

The screening and Travel Rule providers you already use or choose. We connect them to your workflow, we do not replace them.

Who makes the risk decision in a Routescan compliance workflow?

Your team. We bring together activity, provider results and your rules. The decision and its rationale stay with your reviewers.

How are unknown screening results shown?

The result is marked unknown, with its source and date. Missing coverage is never reported as a clear result.

Where are our compliance records stored?

Where your agreement says, with access limited to your organization. Retention is agreed with your compliance team.

How long does it take to set up Pre-transaction Policy Controls?

It depends on the scope. We review the requirements and integrations, then agree a written plan, schedule and responsibilities.

Do we need to build anything to use Pre-transaction Policy Controls?

We handle setup and operations within the agreed scope. Before work starts, we define any integration tasks your team needs to complete.

How is Pre-transaction Policy Controls priced?

The price depends on what we build, the integrations and the ongoing work. Your proposal lists deliverables, timeline and support. Data usage and services from other providers are listed separately where they apply.