> ## Documentation Index
> Fetch the complete documentation index at: https://dev.enterprise.moonpay.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Limits and Minimums
> Transaction spending limits and minimum amounts per risk tier. Covers 52-week rolling limits per direction, verification requirements, and minimum transaction sizes.
## Spending Limits
Individual customer limits are calculated dynamically from the income and wealth information collected during KYC (the wealth questionnaire). There is no single fixed limit. The wealth questionnaire is what derives each Tier 1 customer's personalized cap, so higher declared income produces a higher limit with fewer manual reviews. The limit can be increased to Tier 2 (unlimited) by completing additional due diligence (compliance questionnaire and Source of Wealth proof).
Tier 1 limits apply **per direction**, tracked separately for fiat onramp and crypto offramp, measured on a 52-week rolling window that ends now. If compliance resets a direction, that direction's window starts at the reset instead, so the two windows can differ. Business customers (KYB) have no enforced limit.
| Risk Category | Tier (Access Level) | Limit per Direction (52-week rolling) | Required Verification |
| - | - | - | - |
| Low and medium risk | Tier 1 | Dynamic (based on declared income) | Government-issued ID + Liveness check + KYC Questionnaire + Proof of address (conditional in the USA, EEA, and UK; always required elsewhere) |
| | Tier 2 | Unlimited | Government-issued ID + Liveness check + Proof of address + KYC Questionnaire + SoW proof |
| High risk | N/A | Unlimited | Government-issued ID + Liveness check + Proof of address + KYC Questionnaire + SoW proof |
Proof of address at Tier 1 depends on where the customer resides. Customers residing outside the USA, EEA, and UK always provide one, including Australia. For USA, EEA, and UK residents, MoonPay Enterprise requests it only on specific triggers, and those triggers differ by region. At Tier 2 and for high-risk customers, proof of address is always required. See [Proof of Address](/proof-of-address) for the region-by-region triggers.
Because Tier 1 limits are personalized per customer, do not hard-code a threshold. Read the live value from [Get customer spending limit usage](/reference/customer/get-customer-spending-limit-usage) (`threshold` per direction). The per-direction limit is **not** a combined cap: a Tier 1 customer can spend up to their limit on fiat onramp **and** up to their limit on crypto offramp within the same 52-week window before either direction triggers a tier upgrade.
## Checking Remaining Spending Limit
Poll [Get customer spending limit usage](/reference/customer/get-customer-spending-limit-usage) to read a customer's exact `used` and `remaining` per direction. Use it to trigger proactive EDD before they hit a threshold, instead of waiting for a paused transaction.
To read a customer's live usage, call [Get customer spending limit usage](/reference/customer/get-customer-spending-limit-usage). The response returns `threshold`, `used`, and `remaining` per direction (fiat on-ramp and crypto off-ramp), in `currency` cents as strings, where `currency` is the customer's fiat currency. `threshold` and `remaining` are `null` for Business customers and Regulated persons (no enforced cap).
The response also includes `threshold_eur`, `used_eur`, and `remaining_eur`, EUR-converted views of the same values. These are deprecated: use `threshold`, `used`, and `remaining` instead.
## Proactively Increasing Customer Limits
Partners can proactively upgrade a customer to Tier 2 (unlimited) by initiating Enhanced Due Diligence (EDD) upfront, before the customer hits any spending threshold. This avoids transaction pauses and provides a smoother experience for high-volume customers.
### How to Trigger EDD
When creating an identification via the [Create Customer Identification V2](/reference/customer/create-customer-identification-v2) endpoint, you can trigger EDD depending on the identification type:
**Link flow.** Set `with_edd` to `true`:
```json theme={null}
{
"type": "Link",
"with_edd": true
}
```
**Token flow.** Include `edd_questionnaire` in the request body. See [SumSub Token Sharing](/reliance-kyc-token-sharing#with-kyc--edd-questionnaire) for the full example and field reference.
**Person flow (KYC/KYB Sharing).** Include `edd_questionnaire` in the Person params. See [KYC/KYB Sharing](/sharing#triggering-edd) for details.
### How It Works
* If the customer already has an approved KYC, MoonPay Enterprise will reuse it and only prompt for the additional EDD steps (no duplicate verification required).
* If the customer has not yet completed KYC, the full KYC + EDD flow will be initiated.
* The same identification URL used for regular KYC is used for KYC + EDD, so partners can copy the link from the Partner Dashboard as usual.
Once the identification is created, the `with_edd` field on the [Identification response](/onboarding#tracking-edd-status) indicates whether EDD was applied. This field is also set automatically when MoonPay Enterprise's AML checks determine EDD is required.
Proactive EDD is only available for individual customers. Business customers (KYB) are not supported.
## Handling Transactions Paused Due to Limit Thresholds
MoonPay Enterprise sets spending limits per customer to support its risk-based approach to transactions oversight. When a customer reaches their threshold, transactions are paused until further verification is completed.
### How It Works
When a customer hits their transaction or balance limit:
* The transaction is **paused**.
* The customer's status moves to `IdentificationRequired`.
* MoonPay Enterprise triggers a **tier upgrade**, requiring additional identity verification (including Source of Wealth, "SoW").
* The partner is responsible for providing the customer with the identity link for the tier upgrade.
### Partner Responsibilities
Do one of the following:
* Provide the customer with the identity link for the tier upgrade.
* Contact the end customer, collect the required document (the Source of Wealth proof), and pass it to the MoonPay Enterprise compliance team.
### Timing
* If the customer submits the documents **within 24 hours**, MoonPay Enterprise reviews, clears the transaction, and can **raise the customer's limit**.
* If the customer fails to provide the required documents in time, the transaction is **rejected and returned**.
### Bank-Triggered Blocks
In some cases, a **banking partner** may block a transaction due to compliance concerns. MoonPay Enterprise's compliance team will:
* Contact the partner and request additional customer documentation (typically the SoW proof).
* Optionally, set the customer status to `IdentificationRequired`.
* The partner should assist the customer in providing the documents promptly to avoid transaction rejection.
### Important Notes
* MoonPay Enterprise's compliance team can apply new limit thresholds after reviewing the submitted documentation.
* If the document arrives **after** the 24-hour window, compliance can still raise the limit, but the original transaction does not resume. You must retry it.
## Source of Wealth (SoW) Document Requirements
Source of Wealth proof is required to upgrade a customer to Tier 2 and for Enhanced Due Diligence. For accepted documents by source and acceptance criteria, see [Source of Wealth](/source-of-wealth).
## Minimum Transaction Amount
The minimum supported amount depends on the payout method. Any request below the applicable threshold is rejected and not executed, because processing and network costs would exceed the transferred value.
| Transaction type | Minimum amount |
| - | - |
| Standard onramp and offramp | **1** unit of the payout currency (e.g. 1 EUR, 1 USD) |
| SWIFT / wire payouts | **5** units of the payout currency |
| Stablecoin mint and redeem | **10** units of the input currency |
When a deposit arrives but the resulting payout would fall below the applicable minimum, the deposit is returned to the customer.
Incoming crypto deposits worth less than `1 EUR` (or equivalent) are treated as dust. They are not processed and are not returned.
Communicate these minimums to your end users, especially during onboarding or when guiding them through their first test transaction. This helps avoid confusion and unnecessary troubleshooting.
## Micro-Deposits (Penny Tests)
Some banks and payroll providers verify a Virtual Account by sending a small test deposit before routing real payments to it. MoonPay Enterprise supports two ways to detect these deposits, depending on the rail.
### ACH: Microdeposits
Microdeposits are supported in both the API and dashboard.
* **API:** `GET /api/customers/{id}/microdeposits` returns microdeposits for a customer. See [Get customer microdeposits](/reference/customer/get-customer-microdeposits).
* **Dashboard:** **Customers → select customer → Microdeposits**. Shows amount, currency, counterparty and date. The section is hidden when there are no records.
### All rails: below-minimum rejection webhook
SEPA and other rails carry no scheme-level micro-deposit flag, so detection runs through the transaction lifecycle:
* Send a deposit below the applicable minimum (for example 0.01 EUR) from the bank account you want to verify to your Virtual Account.
* The deposit creates a transaction that is rejected with `transaction_status: RejectedMinAmount`. This is a terminal status: the funds are not converted and no payout is executed.
* MoonPay Enterprise sends a [transaction status webhook](/webhooks) for the rejection. Watch for `transaction_status` set to `RejectedMinAmount` on your webhook endpoint.
* The webhook payload carries the transaction `id` and status, not the amount. Fetch the transaction with [Get autoramp transactions by transaction IDs](/reference/autoramp/get-autoramp-transactions-by-transaction-ids) and confirm the amount and deposit account match the test you sent.
The deposit must land on a Virtual Account with an active Autoramp. If it does not match one (for example, a payment-by-reference account receiving a deposit without the expected reference), MoonPay Enterprise returns the deposit and no transaction or webhook is created. See [When no transaction appears](/transaction-status#when-no-transaction-appears).