--- title: "Open deposit account" method: POST path: "/v1/deposits/accounts/open" tags: ["Deposit account open"] --- # Open deposit account `POST /v1/deposits/accounts/open` Create or locate a transaction banking account and attach a validated deposit product in a single request. On success, the endpoint generates a [Deposit account opened event](https://developers.pismo.io/events/docs/deposit-product-deposit-account-opened-1). This endpoint supports two scenarios: * **Existing account**: Provide both `account.account_id` and `account.external_account_id`. The Pismo platform locates the account via the transaction banking API and validates the IDs. If there is a mismatch, the request fails with a `400` error. * **New account**: Provide `account.external_account_id` and the `account_creation` object. The Pismo platform creates a new transaction banking account and attaches the deposit product. If the transaction banking API returns `409` because the account already exists, the Pismo platform locates the existing account and proceeds with product attachment. **Note**: The deposit product must exist, be of type `deposit`, and have an `ACTIVE` status. ## Headers - `AuthorizationToken` string, required ## Request body - UnifiedDepositOpenRequest — Creates or locates a deposit account and attaches a deposit product in a single request. - `account` UnifiedOpenAccount, required — Identifies the account to which the deposit product is attached - `external_account_id` string, required — The external account ID identifies the transaction banking account. The Pismo platform uses this ID to find the account via the transaction banking API and attach the specified deposit product. - `account_id` integer — Pismo account ID. When provided, the Pismo platform locates the account using `external_account_id` and validates the ID. If omitted, the Pismo platform uses `account_creation` to create a new account. - `deposit_attachment` UnifiedOpenDepositAttachment, required — Deposit product attachment configuration - `product_id` string, required — Product ID of the deposit product to attach - `deposit_configs` DepositConfigs - `maturity_period` MaturityPeriod — Defines when the deposit matures. There are three usage modes: * **Relative period**: Sends `unit` + `value` (e.g. `MONTHS` + `6`). * **Explicit date**: Sends `calendar_maturity_date` (e.g. `2027-06-15`). * **Default**: Omits the field or sends `{}`. The product's configured default maturity term (`PRODUCT_DEFAULT_MATURITY_DATE_DAYS`, typically `10950` days ≈ 30 years) is applied. **NOTE**: `calendar_maturity_date` and `unit`/`value` are mutually exclusive, sending both in the same request returns a `400` validation error. The response returns exactly what was sent in the request: * Send `unit` + `value` returns `unit` + `value` * Send `calendar_maturity_date` returns `calendar_maturity_date` * Send nothing (default fallback applied) returns `unit=DAYS` and `value` equal to the product's configured `PRODUCT_DEFAULT_MATURITY_DATE_DAYS` - `unit` 'DAYS' | 'WEEKS' | 'MONTHS' | 'YEARS' — Time unit for the relative maturity period. It's used together with `value` and cannot coincide with `calendar_maturity_date`. - `DAYS`: Uses `value` directly. Example: `value=90` → 90 days. - `WEEKS`: Multiplies `value` by 7. Example: `value=4` → 28 days. - `MONTHS`: Calculates calendar-month with end-of-month (EOM) clamping when the target day does not exist. Example: `2024-01-31` + 1 month = `2024-02-29` (leap year) or `2025-02-28` (non-leap year). - `YEARS`: Calculates calendar-year, for example: `2024-02-29` + 1 year = `2025-02-28`. Note that there is no Feb 29 in 2025. For `WEEKS`, `MONTHS`, and `YEARS`, the resulting calendar date is converted back to a day count to validate against the product's configured minimum or maximum term. - `value` integer — Number of time units until maturity. Must be greater than `0`. Mutually exclusive with `calendar_maturity_date`. - `calendar_maturity_date` string, date — Maturity date. Format is `YYYY-MM-DD`. The date must be a future date. This date cannot coincide with `unit`/`value`, sending both in the same request returns a `400` validation error. - `payout_account` PayoutAccount — The payout account defines where outbound payments are sent, and it is used in two operational contexts.
* **Capitalization flow**: When the capitalization mode is set to `PAYOUT`, the capitalized interest is directed to this account. If the mode is `REINVEST`, the payout account is not involved because the interest is added to the principal instead. * **Maturity instruction flow**: At maturity, this account receives principal or interest whenever the maturity instructions specify `PAY` for either `maturity_instructions.principal` or `maturity_instructions.interest`. This flow always relies on the payout account, regardless of how capitalization is configured. Both flows reference the same payout account settings. Choosing `REINVEST` for capitalization does not remove or disable the payout account, and it remains fully available for maturity‑related payments. - `label` string — Label to identify the account - `type` 'INTERNAL' | 'EXTERNAL' — Payout account type, either `INTERNAL` or `EXTERNAL` - `internal_account_id` number — Internal account ID for the account that receives the payments. Required for type `INTERNAL` and not allowed for `EXTERNAL`. - `external_account` object — Contains user-defined key-value pairs that identify the external account receiving the payments. Note that external account information is client-provided. Required for type `EXTERNAL` and not allowed for `INTERNAL`. - `interest_capitalization_mode` 'PAYOUT' | 'REINVEST' — Controls the treatment of capitalized interest.
* `PAYOUT` is the default behavior. In this mode, the capitalized amount is sent to the configured payout_account. If no payout account exists, the amount stays in the base account. * `REINVEST` instructs the Pismo platform to add the capitalized amount to the principal through the interest engine. The new principal becomes the foundation for the next accrual cycle. This setting affects only the capitalization process. The maturity instruction flow always uses `payout_account`, regardless of the value of this field. If the field is not provided, it is omitted from the attachment and the Pismo platform applies `PAYOUT` at runtime. - `overrides` AttachmentOverridesRequest — Per-attachment overrides applied on top of the product defaults. All sub-fields are optional. This object contains the per‑attachment overrides that supplement the product defaults. All sub‑fields are optional. Omitting a section causes the Pismo platform to follow the normal fallback sequence, moving from the account level to the program and then to the product defaults. Each penalty type provides `waived` as a required field, optional type‑specific fields, and an optional `valid_until` to schedule the revert. - `maturity_instructions` MaturityInstructionsOverrideRequest — Overrides the deposit’s behavior at maturity. If a field is omitted, the Pismo platform uses the value defined at the higher‑level configuration that governs this deposit. - `principal` 'ROLLOVER' | 'PAY' — Specifies how the principal is handled once the deposit matures. - `interest` 'ROLLOVER' | 'PAY' — Specifies how the interest is handled once the deposit matures. - `reason` string — Optional audit-trail reason. - `renewal_term` RenewalTermOverrideRequest — Specifies the recurring rollover term, not to be confused with the initial `maturity_period`. You must provide either `unit` with `value` or `renewal_calendar_maturity_date`. A `ROLLOVER` configuration in principal or interest is required. When you pass `renewal_calendar_maturity_date`, the Pismo platform converts the interval from today into a day count and stores it at attach time in normalized form: `{unit: DAYS, value: }`. - `unit` 'DAYS' | 'WEEKS' | 'MONTHS' | 'YEARS' — Time unit of the renewal term. Required together with `value` when calendar form is not used. - `value` integer — Number of units. Required together with `unit` when calendar form is not used. - `renewal_calendar_maturity_date` string, date — Explicit calendar date (`YYYY-MM-DD`), the date must be a future date, and does not coincide with `unit`+`value`. - `penalties` PenaltiesOverrideRequest — Per-type penalty overrides. Each type independently uses three-state semantics: omit (inherit) · `{waived: true}` (exempt) · `{waived: false, }` (customize). - `reason` string — Optional audit-trail reason for the entire penalties block. - `grace_period` GracePeriodOverrideRequest — Grace period override. Type-specific fields are optional pointers, when omitted, the Pismo platform follows the normal fallback sequence, moving from the account level to the program and then to the product defaults. - `waived` boolean, required — `true` = fully exempt; `false` = penalty active (customize via the fields below). - `duration_days` integer - `penalty_interest_days` integer - `valid_until` string, date-time — Schedules the revert of this override via EventBridge. This value must be a future date and follows the ISO 8601 standard. - `early_withdrawal_after_opening` EarlyWithdrawalAfterOpeningOverrideRequest — Override for early withdrawal after account opening. - `waived` boolean, required - `applicable_within_days` integer - `penalty_interest_days` integer - `valid_until` string, date-time - `withdrawal_fee` WithdrawalFeeOverrideRequest — Withdrawal fee override. - `waived` boolean, required - `type` 'PERCENTAGE' | 'FIXED' - `value` number - `valid_until` string, date-time - `tiered_interest_forfeiture` TieredInterestForfeitureOverrideRequest — Tiered interest forfeiture override. Tiers replace the product's tiers when provided. - `waived` boolean, required - `tiers` TieredInterestForfeitureTierRequest[] - … - `valid_until` string, date-time - `subsequent_withdrawals` SubsequentWithdrawalsOverrideRequest — Subsequent withdrawals (Regulation D) override. - `waived` boolean, required - `applicable_within_days` integer - `penalty_interest_days` integer - `window_behavior` 'ROLLING' | 'FIXED' - `valid_until` string, date-time - `account_creation` UnifiedOpenAccountCreation — Account creation parameters. Required when `account.account_id` is not provided. Pismo platform uses these fields to create a new transaction banking account via the transaction banking API. - `program_id` integer, required — Program ID to associate the new account with - `division_code` string, required — Division code for the new account - `applicant` UnifiedOpenApplicant, required — Applicant information for account creation - `document_number` string, required — Applicant document number. For example, CPF or the US social security number. - `name` string, required — Applicant's full name - `currency_code` string — ISO 4217 currency code for the account. If omitted, the default currency for the program is used. - `account_creation_datetime` string, date-time — Account creation timestamp is passed directly to the transaction‑banking API as an ISO 8601 value (`yyyy‑mm‑ddThh:mm:ss.sssZ`, 24 characters). The field is optional and omitted when not supplied, and all validation is handled by the transaction banking API. - `metadata` object — The metadata object contains user-defined key-value pairs that provide additional context or custom information.
Metadata content is not controlled by the Pismo platform and is instead controlled by the user.
**Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](https://developers.pismo.io/pismo-docs/reference/get-started-with-pismo-apis). ## Response `201` Deposit account opened successfully - UnifiedDepositOpenResponse — Response returned after successfully opening a deposit account and attaching a product - `account_id` integer — Pismo account ID (new or existing) - `external_account_id` string — External account ID - `product_id` string — Product ID of the attached deposit product - `deposit_configs` object — Deposit configuration after attachment - `maturity_period` MaturityPeriod — Defines when the deposit matures. There are three usage modes: * **Relative period**: Sends `unit` + `value` (e.g. `MONTHS` + `6`). * **Explicit date**: Sends `calendar_maturity_date` (e.g. `2027-06-15`). * **Default**: Omits the field or sends `{}`. The product's configured default maturity term (`PRODUCT_DEFAULT_MATURITY_DATE_DAYS`, typically `10950` days ≈ 30 years) is applied. **NOTE**: `calendar_maturity_date` and `unit`/`value` are mutually exclusive, sending both in the same request returns a `400` validation error. The response returns exactly what was sent in the request: * Send `unit` + `value` returns `unit` + `value` * Send `calendar_maturity_date` returns `calendar_maturity_date` * Send nothing (default fallback applied) returns `unit=DAYS` and `value` equal to the product's configured `PRODUCT_DEFAULT_MATURITY_DATE_DAYS` - `unit` 'DAYS' | 'WEEKS' | 'MONTHS' | 'YEARS' — Time unit for the relative maturity period. It's used together with `value` and cannot coincide with `calendar_maturity_date`. - `DAYS`: Uses `value` directly. Example: `value=90` → 90 days. - `WEEKS`: Multiplies `value` by 7. Example: `value=4` → 28 days. - `MONTHS`: Calculates calendar-month with end-of-month (EOM) clamping when the target day does not exist. Example: `2024-01-31` + 1 month = `2024-02-29` (leap year) or `2025-02-28` (non-leap year). - `YEARS`: Calculates calendar-year, for example: `2024-02-29` + 1 year = `2025-02-28`. Note that there is no Feb 29 in 2025. For `WEEKS`, `MONTHS`, and `YEARS`, the resulting calendar date is converted back to a day count to validate against the product's configured minimum or maximum term. - `value` integer — Number of time units until maturity. Must be greater than `0`. Mutually exclusive with `calendar_maturity_date`. - `calendar_maturity_date` string, date — Maturity date. Format is `YYYY-MM-DD`. The date must be a future date. This date cannot coincide with `unit`/`value`, sending both in the same request returns a `400` validation error. - `renewal_term` object — Renewal term configuration, present only when the override includes a renewal term. - `unit` 'DAYS' | 'WEEKS' | 'MONTHS' | 'YEARS' — Time unit for the relative maturity period. It's used together with `value` and cannot coincide with `calendar_maturity_date`. - `DAYS`: Uses `value` directly. Example: `value=90` → 90 days. - `WEEKS`: Multiplies `value` by 7. Example: `value=4` → 28 days. - `MONTHS`: Calculates calendar-month with end-of-month (EOM) clamping when the target day does not exist. Example: `2024-01-31` + 1 month = `2024-02-29` (leap year) or `2025-02-28` (non-leap year). - `YEARS`: Calculates calendar-year, for example: `2024-02-29` + 1 year = `2025-02-28`. Note that there is no Feb 29 in 2025. For `WEEKS`, `MONTHS`, and `YEARS`, the resulting calendar date is converted back to a day count to validate against the product's configured minimum or maximum term. - `value` integer — Number of time units until maturity. Must be greater than `0`. Mutually exclusive with `calendar_maturity_date`. - `renewal_calendar_maturity_date` string, date — Explicit renewal maturity date - `payout_account` PayoutAccount — The payout account defines where outbound payments are sent, and it is used in two operational contexts.
* **Capitalization flow**: When the capitalization mode is set to `PAYOUT`, the capitalized interest is directed to this account. If the mode is `REINVEST`, the payout account is not involved because the interest is added to the principal instead. * **Maturity instruction flow**: At maturity, this account receives principal or interest whenever the maturity instructions specify `PAY` for either `maturity_instructions.principal` or `maturity_instructions.interest`. This flow always relies on the payout account, regardless of how capitalization is configured. Both flows reference the same payout account settings. Choosing `REINVEST` for capitalization does not remove or disable the payout account, and it remains fully available for maturity‑related payments. - `label` string — Label to identify the account - `type` 'INTERNAL' | 'EXTERNAL' — Payout account type, either `INTERNAL` or `EXTERNAL` - `internal_account_id` number — Internal account ID for the account that receives the payments. Required for type `INTERNAL` and not allowed for `EXTERNAL`. - `external_account` object — Contains user-defined key-value pairs that identify the external account receiving the payments. Note that external account information is client-provided. Required for type `EXTERNAL` and not allowed for `INTERNAL`. - `maturity_instructions` MaturityInstructionsOverrideRequest — Overrides the deposit’s behavior at maturity. If a field is omitted, the Pismo platform uses the value defined at the higher‑level configuration that governs this deposit. - `principal` 'ROLLOVER' | 'PAY' — Specifies how the principal is handled once the deposit matures. - `interest` 'ROLLOVER' | 'PAY' — Specifies how the interest is handled once the deposit matures. - `reason` string — Optional audit-trail reason. - `penalties` PenaltiesOverrideRequest — Per-type penalty overrides. Each type independently uses three-state semantics: omit (inherit) · `{waived: true}` (exempt) · `{waived: false, }` (customize). - `reason` string — Optional audit-trail reason for the entire penalties block. - `grace_period` GracePeriodOverrideRequest — Grace period override. Type-specific fields are optional pointers, when omitted, the Pismo platform follows the normal fallback sequence, moving from the account level to the program and then to the product defaults. - `waived` boolean, required — `true` = fully exempt; `false` = penalty active (customize via the fields below). - `duration_days` integer - `penalty_interest_days` integer - `valid_until` string, date-time — Schedules the revert of this override via EventBridge. This value must be a future date and follows the ISO 8601 standard. - `early_withdrawal_after_opening` EarlyWithdrawalAfterOpeningOverrideRequest — Override for early withdrawal after account opening. - `waived` boolean, required - `applicable_within_days` integer - `penalty_interest_days` integer - `valid_until` string, date-time - `withdrawal_fee` WithdrawalFeeOverrideRequest — Withdrawal fee override. - `waived` boolean, required - `type` 'PERCENTAGE' | 'FIXED' - `value` number - `valid_until` string, date-time - `tiered_interest_forfeiture` TieredInterestForfeitureOverrideRequest — Tiered interest forfeiture override. Tiers replace the product's tiers when provided. - `waived` boolean, required - `tiers` TieredInterestForfeitureTierRequest[] - `min_days_held` integer, required - `max_days_held` integer — Optional. Open-ended tier when omitted. - `forfeited_interest_days` integer, required - `valid_until` string, date-time - `subsequent_withdrawals` SubsequentWithdrawalsOverrideRequest — Subsequent withdrawals (Regulation D) override. - `waived` boolean, required - `applicable_within_days` integer - `penalty_interest_days` integer - `window_behavior` 'ROLLING' | 'FIXED' - `valid_until` string, date-time ## Other responses - `400` — Bad Request - `403` — Forbidden - `404` — Not Found - `409` — Conflict - `500` — Internal Server Error - `502` — Bad Gateway - `504` — Gateway Timeout --- [API](https://skmtc.net/pismo/apis/platform-authentication.md) · [All operations](https://skmtc.net/pismo/apis/platform-authentication/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/pismo/platform-authentication/revisions/935b62e16de4/schema)