Skip to main content
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.
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:
1

Verify the user

Onboard and verify your user as normal (see Onboarding customers). Once verification.status is verified, check for regional requirements.
2

Check requirements

Call GET /v1/users/me/compliance/requirements. It reports whether this user’s region requires anything and which fields are outstanding.
3

Collect and submit

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

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.

​
Submit the fields

Submit all fields together. Validate on your side first — the request is rejected as a whole if anything is invalid.
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

  • 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

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:
Use these exact accountPurpose values — anything else is rejected. Build your dropdown from this list.

​
Errors

Errors follow the standard problem-details format.
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

Onboarding customers

Create and verify the user before checking compliance.

Errors

Parse problem responses consistently.