> ## Documentation Index
> Fetch the complete documentation index at: https://developer.fin.com/llms.txt
> Use this file to discover all available pages before exploring further.

# June 16, 2026

> Changelog for June 16, 2026

## ✨ New Features

### Customers

1. **New Endpoint: `POST /v2/customers/individual`**
   Create an individual customer with verification details, basic info, address, and financial profile. The customer is created in the `INCOMPLETE` state; attach documents next using `POST /v2/customers/{customer_id}/individual/attach`. The response returns `customer_id` and a `tos_policies_url`. Key fields and behaviors:

   * `basic_info.tax_info` — array of tax documents, each with `country_code`, `document_type`, and `document_id`. Each entry must have a unique `document_id`.
   * `basic_info` — also accepts `middle_name`, `secondary_nationality`, and `gender` (`MALE`, `FEMALE`), alongside `first_name`, `last_name`, `dob`, `email`, `phone`, `country_of_residence`, and `primary_nationality`.
   * `financial_profile.employment_status` — one of `EMPLOYED`, `SELF_EMPLOYED`, `RETIRED`, `STUDENT`, `UNEMPLOYED`.
   * `financial_profile` — uses `occupation_id`, `purpose_id`, `source_of_fund_ids` (array of integer foreign keys), and `monthly_volume_usd`.
   * `address.subdivision_code` — ISO 3166-2 code (for example, `US-CA`). `address.country` must match `basic_info.country_of_residence`.
   * `_en` companions — when a field contains non-ASCII characters, provide a transliterated value in the matching `_en` field (for example, `first_name_en`, `street_line_1_en`).

   The V1 endpoint `POST /v1/customers/individual` remains available. In V2, the single `basic_info.tin` field is replaced by the `tax_info` array:

   | V1 Field         | V2 Field                |
   | ---------------- | ----------------------- |
   | `basic_info.tin` | `basic_info.tax_info[]` |

2. **New Endpoint: `POST /v2/customers/{customer_id}/individual/attach`**
   Attach identifying and address documents to an existing V2 individual customer. The customer ID is now a path parameter, and documents are grouped into typed arrays. Documents are processed asynchronously — a `200` response means the request was validated and queued, and the customer moves to `PROCESSING` once processing completes. Key fields and behaviors:

   * `identifying_documents` — supported `type` values are `PASSPORT`, `NATIONAL_ID`, `DRIVERS_LICENSE`, `RESIDENCE_PERMIT`, and `SELFIE`. At most one non-SELFIE document may be included per request.
   * `NATIONAL_ID`, `DRIVERS_LICENSE`, `RESIDENCE_PERMIT` — require two files, one `FRONT` and one `BACK`. `PASSPORT` and `SELFIE` take a single file.
   * `state` — document issuing state (max 64 characters), required when `type` is `DRIVERS_LICENSE` and `country` is `USA`.
   * `address_documents` — exactly one entry, with a `type` of `UTILITY_BILL`, `GOVERNMENT_LETTER`, or `BANK_STATEMENT`. Its `country` must match the customer's `country_of_residence`.
   * File URIs must be unique across the entire request and must belong to the customer. Only one attach can be in flight per customer; a concurrent attach returns `409`.

   The V1 endpoint `POST /v1/customers/individual/attach` remains available. In V2, the single proof objects are replaced by typed document arrays, and `customer_id` moves from the body to the path:

   | V1 Field             | V2 Field                       |
   | -------------------- | ------------------------------ |
   | `proof_of_identity`  | `identifying_documents[]`      |
   | `proof_of_address`   | `address_documents[]`          |
   | `customer_id` (body) | `customer_id` (path parameter) |