> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cardinalweb3.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SafeReceive

> Protect incoming funds with direction-aware source screening and provenance evidence.

SafeReceive extends Cardinal's existing transaction check. It does not create a second risk engine or replace SafeSend.

<Warning title="Controlled pilot">
  The connected SafeReceive pilot screens the source wallet, returns normalized evidence and applies the same policy contract used by the Protection API. The investor-demonstration BLOCK address uses clearly labelled synthetic evidence. Licensed production-provider coverage and deeper provenance tracing remain roadmap work.
</Warning>

<Card title="Open the SafeReceive pilot" icon="arrow-up-right-from-square" href="https://cardinalweb3.com/app/receive">
  Run the controlled ALLOW, REVIEW and BLOCK scenarios and generate a comprehensive report.
</Card>

## Incoming check

Set `direction` to `incoming`. Cardinal treats `from_address` as the source of funds and `to_address` as the receiving wallet.

```json theme={"dark"}
{
  "from_address": "0xSource",
  "to_address": "0xReceivingWallet",
  "chain": "ethereum",
  "token": "USDC",
  "amount": 5000,
  "direction": "incoming",
  "policy_id": "cardinal-enterprise-demo-v0"
}
```

## Response requirements

SafeReceive keeps the normal risk response and adds:

* `screening.direction` to confirm incoming evaluation
* `screening.subject_address` to identify the screened source
* `screening.provider_mode` to distinguish local, external-ready, and degraded results
* `screening.evidence` with category, severity, confidence, source, and freshness
* `policy.matched_rules` to explain the final action

## Investor-demo scenarios

| Scenario | Expected result |
| - | - |
| Clean source with current evidence | `ALLOW` |
| Unclear, stale, incomplete, or degraded provenance | `REVIEW` with the matched rule |
| High-confidence illicit exposure | `BLOCK` with source and freshness |

The reserved BLOCK scenario demonstrates three synthetic evidence categories: stolen-funds exposure, sanctions-list exposure, and illicit-service association. Each record includes a Cardinal demonstration reference, confidence, severity, and observation time. Do not represent this controlled fixture as a claim about a real person, business, bank account, or wallet.

## Comprehensive Risk Report

After a payment check, an authorised partner can generate a separately metered, immutable report linked to the original `request_id`.

```http theme={"dark"}
GET /api/reports/pricing
POST /api/reports/address
```

```json theme={"dark"}
{
  "request_id": "req_2f57f5db-5f78-46db-9a49-534d99b37d08",
  "business_reference": "Property deposit · Client 1842"
}
```

The report retains:

* the screened source wallet and incoming-payment details
* the original decision, risk score, and check time
* findings and matched policy rules
* named evidence sources, confidence, freshness, and references
* a source-of-funds and exposure-path summary when the approved evidence supports one
* attributed exchange, custodian, service, or institution details with role, jurisdiction, verification state, address, and supporting reference
* provider coverage and transaction-effects mode
* methodology and limitations

## Institution and bank-origin evidence

Blockchain activity does not normally reveal a customer's bank account or bank name. Cardinal must not infer one from a wallet address alone.

The report may display a named exchange, custodian, payment service, financial institution, or other entity only when an approved source supports the attribution. Suitable sources can include licensed intelligence, verified counterparty data, Travel Rule data, customer-supplied source-of-funds documents, or a confirmed business record.

Each attribution should show:

* entity name and type
* role in the payment path, such as origin, intermediary, exchange, custodian, or destination
* verification status and confidence
* jurisdiction and identifiers when the source permits them
* attributed blockchain address or transaction reference
* evidence source, reference, observation time, and freshness

If evidence supports ransomware, stolen-funds, sanctions, scam, mixer, illicit-service, or other exposure, the report should identify the category, path or relationship, confidence, severity, supporting source, and policy effect. It should not overstate indirect exposure as proof of criminal ownership.

<Warning title="Demonstration data">
  Demo reports may use fictional institution names and synthetic exposure paths. They must be labelled as demonstration evidence and must never be presented as a finding about a real bank, exchange, person, or wallet.
</Warning>

The live controlled pilot records report generation separately from the standard SafeReceive check. Customer charging, approved pricing, and treasury settlement must be configured before commercial billing is represented as active.

Recheck when the source, destination, network, token, amount, or relevant policy changes.

Treat the result as a security decision for the checked intent. Do not present it as a legal opinion or a guarantee that every historical transaction was traced.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.