Skip to main content

​
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 from the customer’s most recent transaction in that direction. Business customers (KYB) have no enforced limit.
Proof of address is conditional at Tier 1. Iron requests it only when the customer’s ID document country differs from their residence country (except EU citizens), their residence permit lacks or mismatches address data, or they reside in or connect from a high-risk jurisdiction. At Tier 2 and for high-risk customers, proof of address is always required. See Proof of Address.
Because Tier 1 limits are personalized per customer, do not hard-code a threshold. Read the live value from Get customer spending limit usage (threshold_eur 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 to read a customer’s exact used_eur and remaining_eur 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. The response returns threshold_eur, used_eur, and remaining_eur per direction (fiat on-ramp and crypto off-ramp), in EUR cents as strings. threshold_eur and remaining_eur are null for Business customers and Regulated persons (no enforced cap).

​
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 endpoint, you can trigger EDD depending on the identification type: Link flow. Set with_edd to true:
Token flow. Include edd_questionnaire in the request body. See SumSub Token Sharing for the full example and field reference. Person flow (Outsourcing). Include edd_questionnaire in the Person params. See Outsourcing for details.

​
How It Works

  • If the customer already has an approved KYC, Iron 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 indicates whether EDD was applied. This field is also set automatically when Iron’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

Iron sets spending limits per customer to support its risk-based approach to transactions oversight. When a customer reaches their threshold, transactions may be temporarily blocked 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.
  • Iron 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

  • Providing the customer with the identity link for the tier upgrade.
  • or contacting the end customer and collecting the required document (the Source of Wealth proof) and passing it to the Iron compliance team

​
Timing

  • If the customer submits the documents within 24 hours, Iron reviews, clears the transaction, and may 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. Iron’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

  • Iron’s compliance team may apply new limit thresholds after reviewing the submitted documentation.
  • Even if the document arrives after the 24-hour window, limits may still be raised, but the original transaction will not automatically resume. It must be retried.

​
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, validity windows, and what Iron cannot accept, see 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. 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.
We recommend that partners clearly communicate these minimums to their 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. Iron supports two ways to detect these deposits, depending on the rail.

​
ACH: Microdeposits endpoint

ACH micro-deposits arrive flagged by the sending bank under the NACHA micro-entries rule, and Iron records them as micro-deposits. Call Get customer microdeposits to read them per customer. Each record includes the amount, currency, timestamp, and counterparty name, so you can match the deposit against the test you expect.

​
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.
  • Iron sends a transaction status webhook 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 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), Iron returns the deposit and no transaction or webhook is created.