> For a complete page index, fetch https://docs.transak.com/llms.txt # MiCA Changes for EEA Users Transak serves users in the **European Economic Area (EEA)** under the EU **Markets in Crypto-Assets Regulation (MiCA)**, as a Crypto Asset Service Provider (CASP) licensed by the **Austrian Financial Market Authority (FMA)**. MiCA adds new requirements for EEA users: a pricing disclaimer on every quote, a one-time consent for existing users, extra KYC data, stricter ID documents, and a restricted token list. This guide explains each change and what you need to update for your integration mode. > **Info** > > These changes apply **only to EEA users**. Users in all other countries see no change. > > Transak enables MiCA for API partners in stages, after the Transak-hosted widget goes live. Your Transak account manager will confirm the go-live date for your API key. Test every change in staging before go-live. ## Who is an EEA user? Transak treats a user as an EEA user when their **KYC country** is one of the 30 EEA countries below. Before the user completes KYC, Transak uses the country you pass in the quote. See [Show the MiCA Quote Disclaimer](#1-show-the-mica-quote-disclaimer). | Region | Countries (ISO code) | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | EU member states (27) | Austria (`AT`), Belgium (`BE`), Bulgaria (`BG`), Croatia (`HR`), Cyprus (`CY`), Czechia (`CZ`), Denmark (`DK`), Estonia (`EE`), Finland (`FI`), France (`FR`), Germany (`DE`), Greece (`GR`), Hungary (`HU`), Ireland (`IE`), Italy (`IT`), Latvia (`LV`), Lithuania (`LT`), Luxembourg (`LU`), Malta (`MT`), Netherlands (`NL`), Poland (`PL`), Portugal (`PT`), Romania (`RO`), Slovakia (`SK`), Slovenia (`SI`), Spain (`ES`), Sweden (`SE`) | | Other EEA countries (3) | Iceland (`IS`), Liechtenstein (`LI`), Norway (`NO`) | The United Kingdom and Switzerland are not part of the EEA. UK users continue to follow the [FCA flow](/guides/how-to-submit-fca). ## Changes at a Glance | Change | Whitelabel API (Non-Auth Reliance and Auth Reliance) | KYC Reliance using Sumsub | KYC Reliance using API | Headless KYC (Transak UI) | | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------- | | [Quote disclaimer](#1-show-the-mica-quote-disclaimer) | Show `MICA_EEA_BUY` / `MICA_EEA_SELL` from `termsIds` | Show from `termsIds` | Show from `termsIds` | Show on your own quote and checkout screens | | [MiCA consent](#2-collect-mica-consent-from-existing-eea-users) | `CONSENT` form and [Submit MiCA Consent](/api/whitelabel/kyc/submit-mica-consent) API | `CONSENT` form and [Submit MiCA Consent](/api/whitelabel/kyc/submit-mica-consent) API | `consent` object in [Identity Details](/api/whitelabel/kyc-reliance-api/kyc-reliance-identity-details) | Handled by Transak | | [Source of income, employment status and nationality](#3-collect-source-of-income-employment-status-and-nationality) | `SOURCE_OF_INCOME` form with new fields | `SOURCE_OF_INCOME` form with new fields | `sourceOfIncome` and `additionalDetails` objects in Identity Details | Handled by Transak | | [Accepted ID documents](#4-accepted-identity-documents) | Handled in the Transak-hosted ID check | Driving licences are not accepted | Do not send driving licences | Handled by Transak | | [KYC refresh](#5-kyc-refresh-for-existing-users) | Handle the normal KYC statuses | Handle the normal KYC statuses | Resubmit when asked | Handled by Transak | | [Restricted tokens and products](#6-tokens-and-products-not-available-to-eea-users) | Handle error `5011` on Get Quote | Handle error `5011` on Get Quote | Handle error `5011` on Get Quote | Handle error `5011` on Get Quote | | [Transaction limits](#7-transaction-limits) | Read limits from Get User Limits | Read limits from Get User Limits | Read limits from Get User Limits | Read limits from Get User Limits | > **Do not cache the KYC status of EEA users** > > An EEA user who was `APPROVED` before MiCA can return `ADDITIONAL_FORMS_REQUIRED` or `NOT_SUBMITTED` from the [Get KYC Requirement](/api/whitelabel/kyc/get-kyc-requirement) API until they complete the new MiCA steps or a [KYC refresh](#5-kyc-refresh-for-existing-users). Always call Get KYC Requirement with a fresh `quoteId` before each order. --- ## 1. Show the MiCA Quote Disclaimer The FMA requires every EEA user to see that the exchange rate is an estimate before they pay. The [Get Quote](/api/whitelabel/lookup/get-quote) API returns this disclaimer as `MICA_EEA_BUY` or `MICA_EEA_SELL` in the `termsIds` array. What you need to do: 1. **Get the quote as the logged-in user.** Pass the user authentication headers so Transak uses the user's KYC country. Without them, `termsIds` is always empty: `quoteCountryCode` and the user's IP do not decide it. Get a new quote once the user logs in. 2. **Show the disclaimer** on both the quote screen and the order confirmation screen, above the button, in full and without scrolling. The user does not need to accept it. How to Display Quote Disclaimers **Required for go-live:** Transak reviews your checkout before enabling EEA users on your API key. A checkout that does not show every disclaimer returned in `termsIds` will not be approved for EEA go-live. --- ## 2. Collect MiCA Consent from Existing EEA Users EEA users who completed KYC with Transak before MiCA must give a one-time MiCA consent. Until they do, the user cannot place orders. ### When it is required The [Get KYC Requirement](/api/whitelabel/kyc/get-kyc-requirement) API returns `ADDITIONAL_FORMS_REQUIRED`, and the [Get Additional Requirements](/api/whitelabel/kyc/get-additional-requirements) API returns a `CONSENT` form. `CONSENT` is usually returned first. Process forms in the order they are returned. ```json { "data": { "formsRequired": [ { "type": "CONSENT" } ] } } ``` New EEA users who complete KYC after MiCA go-live do not get the `CONSENT` form. ### What to show the user Show one screen with the following content. The data fields are read-only. Prefill them from the [Get User Details](/api/whitelabel/user/get-user-details) API. | Element | Content | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Title | Continue with Transak GmbH | | Description | To comply with EU regulations, your Transak services will now be provided by Transak GmbH, our Austrian entity licensed by the Austrian Financial Market Authority (FMA) to operate as a Crypto Asset Service Provider under MiCAR. | | User data (read-only) | Name, address, date of birth and mobile number, with the prompt "Please review your information to continue". | | Support notice | If any of this data is incorrect, contact Transak Support before continuing. | | Consent 1 | I consent to my data being processed by Transak GmbH. | | Consent 2 | I agree with Transak's Terms of Use and Privacy Policy (link to Transak's EU Terms of Use and Privacy Policy). | | Button | Agree & Continue. Keep it disabled until the user checks both consents. | ### How to submit it #### Record the time the user agreed Capture the timestamp when the user clicks **Agree & Continue**, in ISO 8601 format with a time zone offset, for example `2026-11-26T10:15:00Z`. #### Submit the consent Call the [Submit MiCA Consent](/api/whitelabel/kyc/submit-mica-consent) API with the user authentication headers for your flow. **`POST /api/v2/user/consent`** ```json title="POST /api/v2/user/consent" { "consentedAt": "2026-11-26T10:15:00Z" } ``` **`Response`** ```json title="Response" { "data": { "status": "SUBMITTED" } } ``` `SUBMITTED` means the consent was recorded. `FAILED` (still HTTP 200) means it was not, so retry the request. Validation and authentication problems return a 4xx error. See [API Errors](#api-errors). #### Continue the KYC flow Call [Get KYC Requirement](/api/whitelabel/kyc/get-kyc-requirement) again. If it returns `ADDITIONAL_FORMS_REQUIRED`, call [Get Additional Requirements](/api/whitelabel/kyc/get-additional-requirements) and complete the remaining forms. After submitting each form, call Get Additional Requirements again: more forms (for example `IDPROOF`) can appear until Get KYC Requirement returns `APPROVED`. Once it returns `APPROVED`, the user can place orders. `consentedAt` rules: * Use the time the user agreed, not the time you send the request. * Include seconds and a time zone offset (`Z` or `±HH:mm`), for example `2026-11-26T10:15:00Z`, `2026-11-26T10:15:00.000Z` or `2026-11-26T11:15:00+01:00`. Milliseconds are optional. * It cannot be in the future, and it cannot be earlier than Transak's MiCA go-live date. **KYC Reliance using API:** send the same timestamp in the `consent` object of the [Identity Details](/api/whitelabel/kyc-reliance-api/kyc-reliance-identity-details) API instead of calling Submit MiCA Consent. To check whether a user needs it, call [Get KYC Requirement](/api/whitelabel/kyc/get-kyc-requirement) with the `quoteId` and the user authentication headers. If it returns `ADDITIONAL_FORMS_REQUIRED`, call [Get Additional Requirements](/api/whitelabel/kyc/get-additional-requirements). If `formsRequired` contains `type: CONSENT`, send the `consent` object. Otherwise, leave it out. --- ## 3. Collect Source of Income, Employment Status and Nationality EEA users must provide their source of funds, expected monthly volume, employment status and nationality. This applies to **all EEA users**, not only Enhanced KYC. Simple KYC is not offered to EEA users. ### The SOURCE_OF_INCOME form For a new user, Transak decides whether the user is an EEA user from the address country sent with [Patch User Details](/api/whitelabel/kyc/patch-user-details), not from the fiat currency. Until an EEA address is submitted, the `SOURCE_OF_INCOME` form and its EEA options are not returned, so call Get Additional Requirements again after patching the address. For EEA users, the `SOURCE_OF_INCOME` form from [Get Additional Requirements](/api/whitelabel/kyc/get-additional-requirements) returns the options for each field in `metadata`: | Metadata field | Use it for | Returned for | | ----------------------------- | --------------------------------------------- | ------------------------------------------------------------------ | | `sourceOfFundsTypeOptions` | `sourceOfFundsType` dropdown | All users (`options` carries the same list for older integrations) | | `employmentStatusOptions` | `employmentStatus` dropdown | EEA users | | `countryOfCitizenshipOptions` | `countryOfCitizenship` (nationality) dropdown | EEA users | ```json { "data": { "formsRequired": [ { "type": "SOURCE_OF_INCOME", "metadata": { "options": [ { "name": "Salary payments", "value": "salary_payment" }, { "name": "Savings", "value": "savings" } ], "sourceOfFundsTypeOptions": [ { "name": "Salary payments", "value": "salary_payment" }, { "name": "Savings", "value": "savings" } ], "employmentStatusOptions": [ { "name": "Student", "value": "student" }, { "name": "Mid-Level Employee", "value": "mid_level_employee" } ], "countryOfCitizenshipOptions": [ { "name": "Germany", "value": "DE" }, { "name": "France", "value": "FR" } ] } } ] } } ``` The example is shortened. Always build the dropdowns from the options in the response, and send the `value` of the selected option. For EEA users, employment status and nationality are part of the `SOURCE_OF_INCOME` form, not a separate form, so the user completes all four fields on one screen. ### Submit the form Call the [Submit Source of Income](/api/whitelabel/kyc/submit-source-of-income) API: **`POST /api/v2/user/source-of-income`** ```json title="POST /api/v2/user/source-of-income" { "monthlyVolume": "1000", "sourceOfFundsType": "salary_payment", "employmentStatus": "mid_level_employee", "countryOfCitizenship": "DE" } ``` | Field | Description | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `monthlyVolume` | Expected monthly transaction volume, as a numeric string. | | `sourceOfFundsType` | A `value` from `sourceOfFundsTypeOptions`. | | `employmentStatus` | A `value` from `employmentStatusOptions`. Required for EEA users. | | `countryOfCitizenship` | The user's nationality as declared by the user, from `countryOfCitizenshipOptions`. The list contains all countries as ISO 3166-1 alpha-2 codes (for example `DE`, `FR`, `IN`), since an EEA resident can be a national of any country. Required for EEA users. | `SUBMITTED` means the data was recorded. `FAILED` (still HTTP 200) means it was not, so retry the request. Validation and authentication problems return a 4xx error. See [API Errors](#api-errors). ### Employment status values | Value | Label | | ----------------------------- | --------------------------- | | `student` | Student | | `retired` | Retired | | `unemployed` | Unemployed | | `self_employed` | Self Employed | | `junior_entry_level_employee` | Junior/Entry-Level Employee | | `mid_level_employee` | Mid-Level Employee | | `management_role` | Management Role | | `executive_role` | Executive Role | ### Source of funds values `salary_payment`, `savings`, `property_sale`, `sale_of_crypto`, `inheritance`, `pension`, `loan`, `dividends`, `gift_or_donation`, `income_from_services_provided`, `stock_share_sale` --- ## 4. Accepted Identity Documents | User | Accepted ID documents | | ---------------------------------- | ------------------------------------ | | EEA national | Passport, or EU/EEA national ID card | | Non-EEA national living in the EEA | Passport only | Driving licences are **not accepted** for new EEA users or when an existing EEA user verifies again. Existing users who verified with a valid driving licence can continue until the document expires or a KYC refresh is required. * **Whitelabel API and Headless KYC:** the Transak-hosted ID check only offers the accepted documents. No change is needed. * **KYC Reliance using API:** do not send `DRIVING_LICENSE` in [Document Details](/api/whitelabel/kyc-reliance-api/kyc-reliance-document-details) for EEA users. * **KYC Reliance using Sumsub:** share tokens for EEA users must contain a passport or national ID card. --- ## 5. KYC Refresh for Existing Users After the consent step, Transak can ask an existing EEA user to verify again. This happens when, for example, the ID document has expired, the user completed KYC more than 12 months ago, or Transak's risk checks require it. There is **no new KYC status**. A user who needs a refresh returns `NOT_SUBMITTED` or `ADDITIONAL_FORMS_REQUIRED` from [Get KYC Requirement](/api/whitelabel/kyc/get-kyc-requirement). Handle them exactly as in the standard [KYC flow](/integration/api#kyc): patch user details if asked, then complete every form returned by Get Additional Requirements, including a new ID proof check (`IDPROOF`) if returned. **KYC Reliance using API:** if Get KYC Requirement returns `ADDITIONAL_FORMS_REQUIRED` for a returning EEA user, call Get Additional Requirements and submit [Identity Details](/api/whitelabel/kyc-reliance-api/kyc-reliance-identity-details) again with the `sourceOfIncome` and `additionalDetails` objects, plus the `consent` object if `formsRequired` contains `type: CONSENT`. --- ## 6. Tokens and Products Not Available to EEA Users Some crypto assets do not meet MiCA requirements and are not available to EEA users for buying or selling, on any network. These include **USDT**, **DAI**, **PYUSD** and **Tether Gold (XAUT)**. Transak may restrict more assets as regulators publish new guidance. When an EEA user requests a quote for a restricted asset, [Get Quote](/api/whitelabel/lookup/get-quote) returns: ```json { "error": { "statusCode": 400, "message": "You are not allowed to buy USDT on ethereum. Please change the cryptocurrency to proceed", "errorCode": 5011 } } ``` Show the message and ask the user to pick another asset. The following products are not available to EEA users at launch: * [NFT Checkout](/products/nft-checkout) * [Virtual Account Payments](/products/virtual-account-payments) --- ## 7. Transaction Limits EEA users have their own transaction limits, set in EUR, for each payment method and KYC level. Do not hard-code limits. Read them from the [Get User Limits](/api/whitelabel/user/get-user-limits) API for the user before you show the amount screen. --- ## Integration Checklist by Mode #### Non-Auth Reliance For partners using the Whitelabel API with Transak OTP login (`authorization` header). 1. Pass `authorization` on [Get Quote](/api/whitelabel/lookup/get-quote) once the user is logged in. Quotes without it return an empty `termsIds`. 2. Show `MICA_EEA_BUY` or `MICA_EEA_SELL` on the quote and order confirmation screens. 3. Handle the `CONSENT` form: show the consent screen and call [Submit MiCA Consent](/api/whitelabel/kyc/submit-mica-consent). 4. Add `employmentStatus` and `countryOfCitizenship` to your `SOURCE_OF_INCOME` screen, using the options in the form metadata. 5. Do not cache `APPROVED`. Call Get KYC Requirement before every order. 6. Handle error `5011` on Get Quote. 7. Read limits from Get User Limits. #### Auth Reliance For partners using the Whitelabel API with their own login (`x-access-token` and `x-user-identifier` headers). See [Auth Reliance](/features/auth-reliance). 1. Pass **both** `x-access-token` and `x-user-identifier` on [Get Quote](/api/whitelabel/lookup/get-quote) once the user is onboarded. Quotes without both headers return an empty `termsIds`. 2. Show `MICA_EEA_BUY` or `MICA_EEA_SELL` on the quote and order confirmation screens. 3. Handle the `CONSENT` form: show the consent screen and call [Submit MiCA Consent](/api/whitelabel/kyc/submit-mica-consent) with the Auth Reliance headers. 4. Add `employmentStatus` and `countryOfCitizenship` to your `SOURCE_OF_INCOME` screen, using the options in the form metadata. 5. Do not cache `APPROVED`. Call Get KYC Requirement before every order. 6. Handle error `5011` on Get Quote. 7. Read limits from Get User Limits. #### KYC Reliance using Sumsub For partners sharing Sumsub KYC with a share token. See [KYC Reliance using Sumsub](/features/kyc-reliance#using-sumsub). 1. Pass the user authentication headers on Get Quote and Get KYC Reliance Quote so EEA users get `termsIds`. 2. Show `MICA_EEA_BUY` or `MICA_EEA_SELL` on the quote and order confirmation screens. 3. Make sure the Sumsub applicant for EEA users is verified with a passport or national ID card. 4. After the share token is imported, call Get KYC Requirement and Get Additional Requirements. Complete the `CONSENT` and `SOURCE_OF_INCOME` forms through the Whitelabel APIs, as in the Non-Auth Reliance or Auth Reliance tab. 5. Handle error `5011` on Get Quote and read limits from Get User Limits. #### KYC Reliance using API For partners sending their own KYC data. See [KYC Reliance using API](/features/kyc-reliance#using-api). 1. Pass the user authentication headers on Get Quote so EEA users get `termsIds`, and show `MICA_EEA_BUY` or `MICA_EEA_SELL`. 2. **EEA users** (`addressDetails.countryCode` is an EEA country): add the `sourceOfIncome` and `additionalDetails` objects to [Identity Details](/api/whitelabel/kyc-reliance-api/kyc-reliance-identity-details). 3. **Check whether MiCA consent is needed:** call [Get KYC Requirement](/api/whitelabel/kyc/get-kyc-requirement) with the `quoteId`. If it returns `ADDITIONAL_FORMS_REQUIRED`, call [Get Additional Requirements](/api/whitelabel/kyc/get-additional-requirements). If `formsRequired` contains `type: CONSENT`, show the consent screen and send Identity Details again with the `consent`, `sourceOfIncome` and `additionalDetails` objects. 4. Do not send driving licences for EEA users in Document Details. 5. Handle error `5011` on Get Quote and read limits from Get User Limits. **`POST /kyc/v2/reliance/identity-details (EEA user)`** ```json title="POST /kyc/v2/reliance/identity-details (EEA user)" { "personalDetails": { "firstName": "Lena", "lastName": "Schmidt", "dob": "1990-04-12", "mobileNumber": "+4915123456789" }, "addressDetails": { "addressLine1": "Friedrichstrasse 10", "state": "Berlin", "city": "Berlin", "countryCode": "DE", "postCode": "10117" }, "purposeList": ["Buying/selling crypto for investments"], "consent": { "consentedAt": "2026-11-26T10:15:00Z" }, "sourceOfIncome": { "monthlyVolume": "1000", "sourceOfFundsType": "salary_payment", "employmentStatus": "mid_level_employee" }, "additionalDetails": { "countryOfCitizenship": "DE" } } ``` Send `consent` only when Get Additional Requirements returns `type: CONSENT` for the user (step 3). Use the [employment status](#employment-status-values) and [source of funds](#source-of-funds-values) values listed above. #### Headless KYC For partners using the Transak UI SDK for KYC. See [Headless KYC](/features/headless-kyc). 1. Update to the latest Transak UI SDK version. The consent, source of income, nationality and ID document changes are handled inside the Transak UI. 2. If you render your own quote or checkout screens, pass the user authentication headers on Get Quote and show `MICA_EEA_BUY` or `MICA_EEA_SELL`. 3. Handle error `5011` on Get Quote and read limits from Get User Limits. --- ## API Overview #### [Get Quote](/api/whitelabel/lookup/get-quote) Returns `MICA_EEA_BUY` or `MICA_EEA_SELL` in `termsIds` for EEA users. #### [Get Additional Requirements](/api/whitelabel/kyc/get-additional-requirements) Returns the `CONSENT` form and the extended `SOURCE_OF_INCOME` form. #### [Submit MiCA Consent](/api/whitelabel/kyc/submit-mica-consent) Records the time an existing EEA user gave the MiCA consent. #### [Submit Source of Income](/api/whitelabel/kyc/submit-source-of-income) Accepts `employmentStatus` and `countryOfCitizenship` for EEA users. #### [Identity Details (KYC Reliance)](/api/whitelabel/kyc-reliance-api/kyc-reliance-identity-details) Accepts the `consent`, `sourceOfIncome` and `additionalDetails` objects. ## API Errors #### Get Quote | HTTP Status | Error Code | Message | | ----------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 400 | 5011 | You are not allowed to (buy or sell) `` on ``. Please change the cryptocurrency to proceed | | 401 | 1002 | Invalid or missing authentication token (user authentication headers were sent but are invalid) | | 403 | 9001 | Required role 'auth_reliance' not found in user roles (Auth Reliance headers were sent, but the partner access token does not have the `auth_reliance` role) | #### Submit MiCA Consent | HTTP Status | Error Code | Message | | ----------- | ---------- | ------------------------------------------------------------------------------------- | | 400 | 9001 | consentedAt is required | | 400 | 9001 | consentedAt must be a string | | 400 | 9999 | Consent timestamps must be ISO 8601 with a timezone offset, e.g. 2026-09-01T10:15:00Z | | 400 | 9999 | A consent timestamp cannot be in the future | | 400 | 9999 | A consent timestamp cannot pre-date the licence | #### Identity Details (KYC Reliance using API) | HTTP Status | Error Code | Message | | ----------- | ---------- | ------------------------------------------------------------------------------------- | | 400 | 9001 | consentedAt is required | | 400 | 9001 | monthlyVolume is required in sourceOfIncome | | 400 | 9001 | sourceOfFundsType is required in sourceOfIncome | | 400 | 9999 | Monthly volume should be a valid number | | 400 | 9999 | Invalid source of funds type | | 400 | 9999 | Invalid employment status | | 400 | 9999 | Consent timestamps must be ISO 8601 with a timezone offset, e.g. 2026-09-01T10:15:00Z | | 400 | 9999 | A consent timestamp cannot be in the future | | 400 | 9999 | A consent timestamp cannot pre-date the licence |