> For the complete documentation index, see [llms.txt](https://city-protocol.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://city-protocol.gitbook.io/docs/developers/city-protocol-sdk/aml.md).

# AML

Screen wallets and transactions through a pluggable AML provider.

`CityAmlClient` screens wallets and transactions through a pluggable AML provider and returns exposure breakdowns for your own risk controls.

## How it works

`CityAmlClient` follows a provider model: it is provider-agnostic and delegates every screening call to a pluggable provider instance. `EllipticAmlProvider`, created with `ELLIPTIC_API_KEY`, is the current default, and another provider plugs in with no change to application code. Screening runs on your backend. The API key stays server-side, and analysis results carry sensitive customer context, such as risk scores, exposure breakdowns and entity attributions, so the backend never surfaces them raw to end users.

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FeDZZUvx5aSYTgfBpOYZp%2Ffig-sdk-aml.png?alt=media" alt="Deposit screening through analyzeWallet and your threshold, and transaction monitoring through analyzeTransaction and getTransactionAnalysis, both calling CityAmlClient and its provider and both ending in your risk controls"><figcaption><p>Two screening flows through one provider. Every analysis call goes through CityAmlClient and its provider, and every decision to block, flag, freeze or allow sits in your own risk controls.</p></figcaption></figure>

* **Wallet exposure:** `analyzeWallet` with `type` set to `"wallet_exposure"` submits an address, which the provider evaluates against known risk entities, sanctions lists and behavioural heuristics for a holistic inbound and outbound exposure breakdown.
* **Source of funds:** `analyzeTransaction` with `type` set to `"source_of_funds"` submits a transaction hash, together with a `customer_reference` that ties the analysis to your own records.
* **Asynchronous results:** The backend stores the analysis ID that each submission returns and fetches the result once processing completes, with `getWalletAnalysis` or `getTransactionAnalysis`. With `asset` set to `"holistic"`, an analysis covers every supported asset.

Results feed your own risk controls, and every decision, such as blocking a deposit or flagging a user for review, sits downstream of the raw analysis. In deposit screening, a risk score above your threshold blocks the deposit and routes the case to your compliance queue, and any other result lets the vault `deposit` or `mint` proceed through `CityClient`. In transaction monitoring, the analysis of a confirmed deposit drives your policy to flag, freeze or allow.

The provider stores each `customer_reference` with its analysis, so a deterministic format such as `user-123:deposit-456` lets your compliance team trace any flagged analysis back to the originating action, and the reference methods `listSupportedAssets`, `listRiskRules` and `listCriteriaCategories` keep your rule caches and compliance dashboards current.

{% content-ref url="/pages/mLBQFzx1rIEbhJK4SwO9" %}
[Set up the provider](/docs/developers/city-protocol-sdk/aml/set-up-the-provider.md)
{% endcontent-ref %}

{% content-ref url="/pages/J4VMBUGdAqP8tE3bp3YH" %}
[Recommended deployment shape](/docs/developers/city-protocol-sdk/aml/recommended-deployment-shape.md)
{% endcontent-ref %}

{% content-ref url="/pages/vjHTl3Rqje3El64shUCy" %}
[Core analysis methods](/docs/developers/city-protocol-sdk/aml/core-analysis-methods.md)
{% endcontent-ref %}

{% content-ref url="/pages/po9oVdaXF1lcIR15ZfdY" %}
[Reference data](/docs/developers/city-protocol-sdk/aml/reference-data.md)
{% endcontent-ref %}

{% content-ref url="/pages/8uHTl96EUhY7Ient6xCl" %}
[Common integration flows](/docs/developers/city-protocol-sdk/aml/common-integration-flows.md)
{% endcontent-ref %}