> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spritz.finance/llms.txt
> Use this file to discover all available pages before exploring further.
# Regional Compliance
> Collect the extra identity details some regions require before a user can transact.
Some regulatory regions require a few identity details beyond standard verification. Today that means users in the European Economic Area (EEA), under the Markets in Crypto-Assets regulation (MiCA) — but the mechanism is region-neutral: the same two endpoints handle any region Spritz adds.
Everything else about your integration is unchanged. This is one extra step after [onboarding and verification](/guides/onboarding).
This is a **blocking requirement**. Until the user submits these fields, their ramp capabilities (SEPA, ACH, wire) carry a `regional_compliance` requirement and money movement is refused. You can detect it two ways: it appears in the `requirements` array on the user's capabilities — so if you already gate on capabilities you get it for free — and the dedicated endpoint below gives the per-field detail you need to collect what is missing.
## The protocol
The flow is the same for every region:
Onboard and verify your user as normal (see [Onboarding customers](/guides/onboarding)). Once `verification.status` is `verified`, check for regional requirements.
Call `GET /v1/users/me/compliance/requirements`. It reports whether this user's region requires anything and which fields are outstanding.
If required, collect the listed fields and submit them together.
If you already know the user is in a regulated region, you can skip the check and `POST` directly — the submit endpoint validates and rejects users for whom nothing is required.
## Check requirements
```bash theme={null}
curl https://platform.spritz.finance/v1/users/me/compliance/requirements \
-H "Authorization: Bearer ak_USER_KEY"
# plus your integrator signing headers (see Authentication)
```
```json theme={null}
{
"required": true,
"region": "EEA",
"complete": false,
"deadline": "2026-06-26",
"fields": [
{ "field": "placeOfBirth", "status": "missing" },
{ "field": "nationalities", "status": "missing" },
{ "field": "accountPurpose", "status": "missing" }
]
}
```
Act only when `required && !complete`. Otherwise there is nothing to do — a user outside a regulated region returns `required: false, complete: true` with an empty `fields` array, and a user who has already submitted returns `complete: true`.
| Field | Meaning |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `required` | Whether the user's region requires anything. `false` outside such regions. |
| `region` | The region driving the requirement (currently only `EEA`), or `null`. |
| `complete` | Whether every required field has been collected. |
| `deadline` | Bridge's own compliance date for the fields. It does **not** grant a grace period — an EEA user is gated as soon as any field is missing, regardless of this date. |
| `fields` | Per-field status — each `missing` or `complete`. Empty when not required. |
## Submit the fields
Submit all fields together. Validate on your side first — the request is rejected as a whole if anything is invalid.
```bash theme={null}
curl -X POST https://platform.spritz.finance/v1/users/me/compliance \
-H "Authorization: Bearer ak_USER_KEY" \
-H "Content-Type: application/json" \
# plus your integrator signing headers (see Authentication)
-d '{
"placeOfBirth": { "country": "DEU", "city": "Berlin" },
"nationalities": ["DEU"],
"accountPurpose": "personal_or_living_expenses"
}'
```
```json theme={null}
{ "complianceFieldsComplete": true, "bridgeCustomerUpdated": true }
```
`complianceFieldsComplete` is the same signal as `complete` from the requirements endpoint — once it is `true`, the `regional_compliance` requirement clears from the user's capabilities. `bridgeCustomerUpdated` reports whether the fields were forwarded to the provider immediately (`true`) or stored to be sent when the customer is first created (`false`); either way the fields are captured. After a successful submission, re-fetching requirements returns `complete: true`.
## EEA field reference
These are the fields the EEA requires. A future region would list its own fields in the requirements response; this section is EEA-specific.
### placeOfBirth
```json theme={null}
{ "country": "DEU", "city": "Berlin" }
```
* **`country`** (required) — ISO 3166-1 **alpha-3** code. This is the three-letter code (`DEU`, `FRA`, `POL`), not the two-letter code (`DE`). This is the most common integration mistake.
* **`city`** — optional today; required by EU law from 2027.
### nationalities
```json theme={null}
["DEU", "FRA"]
```
An array of ISO 3166-1 **alpha-3** codes, at least one. Include every nationality the user holds, not just their primary one.
### accountPurpose
One of the following, plus a free-text `accountPurposeOther` when `other`:
| Value | Suggested label |
| -------------------------------------- | -------------------------------------- |
| `personal_or_living_expenses` | Personal or living expenses |
| `receive_salary` | Receiving salary |
| `receive_payment_for_freelancing` | Receiving payment for freelance work |
| `payments_to_friends_or_family_abroad` | Payments to friends or family abroad |
| `purchase_goods_and_services` | Purchasing goods and services |
| `ecommerce_retail_payments` | Online shopping and retail payments |
| `operating_a_company` | Operating a company |
| `investment_purposes` | Investing |
| `protect_wealth` | Protecting wealth |
| `charitable_donations` | Charitable donations |
| `other` | Other (requires `accountPurposeOther`) |
```json theme={null}
{
"placeOfBirth": { "country": "FRA" },
"nationalities": ["FRA"],
"accountPurpose": "other",
"accountPurposeOther": "Family remittances"
}
```
Use these exact `accountPurpose` values — anything else is rejected. Build your dropdown from this list.
## Errors
Errors follow the standard [problem-details](/guides/errors) format.
| Status | When |
| ------ | ------------------------------------------------------------------------------------------------------------------------------- |
| `400` | The submission is invalid (bad country code, empty nationalities, missing `accountPurposeOther`, or a purpose not in the list). |
| `400` | Compliance fields submitted for a user whose region does not require them. |
| `409` | The fields raced a concurrent change to the customer record. Safe to retry. |
| `404` | No user record found. |
```json theme={null}
{
"type": "urn:problem-type:validation:invalid-request",
"title": "Invalid Request",
"status": 400,
"detail": "Compliance field validation failed"
}
```
The `detail` is a summary, not a per-field list — validate client-side (country codes alpha-3, at least one nationality, a description when the purpose is `other`) so your users see precise errors before the request is made.
## Next
Create and verify the user before checking compliance.
Parse problem responses consistently.