Financial intelligence for regulated institutions
Digital-asset controls built for institutional finance.
ChainGuard connects blockchain intelligence to institutional governance through sanctions screening, transaction monitoring, investigations, policy decisions and audit evidence for banks, exchanges, custodians and regulated financial institutions.
- Built for
- Banks, payment institutions and regulated digital-asset businesses
- Sits between
- Blockchain activity and the banking systems that act on it
Inbound deposit1.84 BTC
bc1q…7f2d
Compliance outcome recorded. Operational execution stays separately controlled.
This panel cycles through two sanitized examples: a Bitcoin deposit and an Ethereum withdrawal. Together, they show the stages ChainGuard applies to a transfer: observation, source or destination tracing, entity resolution, risk evaluation, banking policy application, decision, and evidence assembly. It does not display live or production data.
Operating context
Controlled deployment inside regulated financial operations. It is a decision and evidence layer, not a public explorer, a standalone screening score or an asset custodian.
The problem
Accepting crypto is a banking-control problem, not only a blockchain-data problem.
Institutions already have access to chain data. What they lack is the layer that turns that data into a decision they can defend to a regulator.
A blockchain explorer shows you a transaction.
A control layer tells you whose funds moved, where they came from, and whether your policy permits the outcome.
A risk score gives you a number.
A banking decision needs the reasoning, the policy version and the evidence behind that number.
An alert queue tells you something happened.
An operating institution needs an explained, approved and recorded outcome for every material case.
Coverage
Bitcoin and the major account-based networks, handled on their own terms.
Bitcoin is not treated as an account ledger with a different logo. Unspent-output lineage and account-graph activity are modelled separately, then expressed through one compliance vocabulary.
- BitcoinBTC
Unspent outputs
- EthereumETH
Account model
- BNB ChainBNB
Account model
- PolygonPOL
Account model
- ArbitrumETH
Account model
- BaseETH
Account model
- OptimismETH
Account model
- AvalancheAVAX
Account model
Bitcoin and unspent-output ledgers
Value moves as spent and newly created outputs rather than account balances. ChainGuard reads input and output context, excludes observed change from outgoing transfer records, and builds a bounded address graph from monitored-wallet activity.
- Input/output context
- Address graph
- Change-output handling
- Confirmation depth
Ethereum and account-based networks
Value moves between persistent accounts and contracts. ChainGuard resolves native and token transfers, contract interactions, bridge and decentralised-exchange routing, and attributes counterparties across the account graph on each supported network.
- Account graph
- Token transfers
- Contract interaction
- Bridge and swap routing
Source and destination
Follow the funds, and say plainly where the trail stops.
ChainGuard traces backwards to the origin of a deposit and forwards to the terminal destination of a withdrawal, attributing each hop where attribution is possible.
- Direct and indirect exposure
- Multi-hop tracing
- Entity attribution per hop
- Known and unknown sources
- Bridge and exchange trace breaks
- Confidence and completeness stated
- Attributed
- Trace break
- Unattributed
bc1q…7f2d
Bitcoin · Address cluster · 412 outputs
Regulated exchange
92%0x4a1e…c093
Ethereum · Account
Payment processor
87%0x8b70…21af
Arbitrum · Account · bridge contact
Cross-chain bridge
74%bc1q…9a04
Bitcoin · Address cluster · 6 outputs
Unattributed cluster
21%
Attribution confidence is reported alongside every resolution. An unattributed cluster is stated as unattributed rather than assumed to be safe.
Entity resolution
An address is not a counterparty. Resolve it to one.
Addresses and unspent-output clusters are grouped and attributed to the financial entity behind them, such as an exchange, bridge, payment processor, mixing service or unattributed cluster. A compliance officer can therefore review counterparties instead of hexadecimal strings.
Decision control
From blockchain signals to a banking decision you can defend.
Every input is combined under a versioned policy that your institution controls. The outcome is recorded with its reasoning, not just its verdict.
- Risk assessment
- Customer context
- Wallet ownership
- Travel Rule status
- Source and destination intelligence
- Versioned banking policy
One recorded decision
- Allow
Policy conditions satisfied
- Hold
Blocked pending resolution
- Review
Routed to an analyst
- Reject
Declined under policy
- Escalate
Raised to a senior approver
Operational execution stays separately controlled. A compliance decision does not itself move funds.
- Policy version
- deposit-policy v4.2
- Priority
- Medium
- Severity
- Elevated
- Triggered rules
- VELOCITY_24H, UNVERIFIED_SOURCE
- Missing data
- None
- Maker / checker
- Pending checker approval
This policy evaluation produced a canonical decision. A successor decision can be issued if new evidence arrives; prior decisions are retained, not overwritten. The compliance outcome is recorded independently of whether operational execution has occurred.
Evidence
Every material decision should be explainable months later.
An evidence package is assembled at decision time and retained. It states what was known, what was inferred, and what could not be established.
Policy version
The exact ruleset in force at decision time
Triggered rules
Which conditions fired, and with what weight
Source facts
Observed on-chain and customer data used
Inferred intelligence
Attribution and tracing conclusions, separated from raw facts
Missing data
What could not be established, stated explicitly
Approval history
Maker, checker and any escalation path
Trace path
The hop-by-hop route reconstructed for the funds
Integrity hashes
Content hashes recorded against the package
Timeline
Chronological record across the case lifecycle
Operations
Three flows, one control path.
Deposits, withdrawals and wallet registration each enter the same sequence. The checks specific to each flow are applied at the right point.
Crypto deposit
Funds arrive from outside the institution.
- Transfer observed on Bitcoin or an account-based network
- Source traced upstream to originating entities
- Risk and customer context evaluated together
- Policy decision recorded before crediting is permitted
Crypto withdrawal
Funds leave towards a counterparty.
- Withdrawal request received with beneficiary details
- Destination forward-traced to terminal entities
- Travel Rule status and ownership evidence checked
- Decision issued; execution remains separately controlled
Wallet registration
A customer declares an address they control.
- Address or unspent-output cluster submitted by the customer
- Ownership evidence collected and reviewed
- Sanctions and exposure screening applied at registration
- Registration approved, held or declined under policy
Control domains
One institutional workflow, six control domains.
Security and architecture
Controls designed for independent validation.
Each institution receives a dedicated deployment. Security controls are designed to be validated within your own assurance programme.
Access control
- Multi-factor authentication
- Role-based access control
- Maker/checker on sensitive actions
Record keeping
- Append-only audit records
- Legal hold on evidence
- Versioned policy and model governance
Deployment isolation
- Isolated database per institution
- Institution-controlled blockchain access
- Secret references, not inline secrets
Fail-closed posture
- Execution flags default off
- Controlled provider adapters
- Dedicated policies, users and roles
Design your institution’s digital-asset control architecture.
We work through your deposit, withdrawal and wallet-onboarding flows, then show the platform against them.