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

# Secured Smart Card

> A charge card secured by funds the cardholder already holds. It runs on credit rails without underwriting, and the security stays accessible — unlike a traditional secured card, the deposit is not locked away.

A Secured Smart Card gives a customer a charge card backed by their own money. What makes it different from a traditional secured card is that the security is **dynamic**: spending power tracks the available balance of a linked deposit account rather than a fixed deposit locked up front. The cardholder keeps access to their funds, and the card's spending power adjusts as they spend, repay, and move money.

That combination — credit rails, no underwriting, funds that stay accessible — is why it works as a credit-building product for customers who could not qualify for an unsecured card.

**Why FinTechs offer it**

* Runs on credit rails, which generally earn higher interchange than debit
* No underwriting or credit check is required
* Payment history can be furnished to the bureaus, so it builds credit
* Credit risk is mitigated by the security the customer already holds

<Note>
  Credit products require specific privileges on your organization. Work with your Synctera Implementation & Onboarding manager before planning one.
</Note>

## Overview

### Key Concepts

<AccordionGroup>
  <Accordion title="Dynamic security">
    The product is two accounts: a deposit account holding the customer's money, and a `CHARGE_SECURED` account the card spends against. The charge account's available credit mirrors the **available balance** of the deposit account.

    The security must be a `CHECKING` or `SAVING` account, named by `security.linked_account_id` on the charge account.

    Because the link is to available balance rather than a locked deposit, the customer can still move their money. Move funds out and spending power falls to match; deposit more and it rises.
  </Accordion>

  <Accordion title="Charge, not revolving">
    The balance must be paid in full each billing cycle. Nothing carries over, so no interest accrues.

    Two settings govern the cycle. `billing_period` sets the frequency and the day the cycle anchors to. `grace_period` sets how many days past the end of the cycle the customer has before payment is due.

    A card that lets balances carry is a different product — see [Revolving Credit Card](/v2/docs/build-revolving-credit-card).
  </Accordion>

  <Accordion title="Credit building">
    Because the account has a balance and a payment history, it can be furnished to the credit bureaus in a way a debit card cannot. This is usually the reason a customer chooses the product.

    Furnishing requires bureau credentialing for your program, arranged with your Synctera representative.
  </Accordion>
</AccordionGroup>

### How Balances Work

This is the part worth understanding before you build, because the two accounts move together and a charge account's balance reads the opposite way to a deposit account's.

```mermaid mermaid theme={"system"}
%%{init: {"fontFamily": "sans-serif"}}%%
flowchart LR
  D["Deposit account<br/>(security)"] -->|"available balance sets<br/>available credit"| C["CHARGE_SECURED<br/>account"]
  C --> K["Credit card"]
```

Starting from a security account funded with $100, the charge account shows $100 of available credit. A \$20 card purchase then does two things at once:

| | Available | Balance |
| - | - | - |
| **Security** | \$80 | \$100 |
| **Secured charge** | \$80 | \$20 |

The purchase reduces available credit on the charge account **and** places a hold on the security for the same amount. The security still holds $100, but only $80 of it is available. That hold stays until the charge balance is repaid.

<Info>
  A secured charge account is a **credit** account, so its balance expresses what has been **spent**, not what is held. This is the opposite of a `CHECKING` or `SAVING` account. Keep the distinction in mind when you display balances to customers.
</Info>

If the customer then moves money out of the security, available credit falls to match — the security's available balance is always what governs. A transfer that would take available balance below the outstanding hold fails with a balance violation.

For the full worked sequence, including repayment, see [Balance management](/v2/docs/secured-sc-accounts-guide#balance-management).

### How It Differs from Other Cards

| | Secured Smart Card | Unsecured Charge Card | Revolving Credit Card | Debit |
| - | - | - | - | - |
| Backed by | The customer's own deposits | A credit line | A credit line | The deposit account itself |
| Underwriting | None | Required | Required | None |
| Carrying a balance | Not allowed | Not allowed | Allowed | Not applicable |
| Interest | None | None | On carried balances | None |
| Builds credit | Yes | Yes | Yes | No |
| Account type | `CHARGE_SECURED` | `CHARGE_UNSECURED` | `CREDIT_CARD` | `CHECKING` |

### Who Decides What

| Responsibility | Who |
| - | - |
| **Credit limit** | Effectively the customer, through what they hold in the security account. No credit decision is made. |
| **Authorization** | Synctera, against available credit, account standing, spend controls, and fraud rules. |
| **Repayment** | The customer, in full each cycle — or Synctera, if autopay is enabled. |
| **Statements** | Synctera generates a combined statement covering both accounts. |
| **Bureau furnishing** | Synctera, once credentialing is in place. |

## API Flow

```mermaid mermaid theme={"system"}
%%{init: {"fontFamily": "sans-serif"}}%%
flowchart TB
  A["Create and verify the customer"] --> B["Record disclosures"]
  B --> C["Create the deposit account<br/>(the security)"]
  C --> D["Create the CHARGE_SECURED account<br/>linked to the security"]
  D --> E["Issue the card"]
  E --> F["Enable autopay, if offered"]
```

### Step 1 — Create and Verify the Customer

Create the person and complete KYC. See [Create a Personal Customer](/v2/docs/create-a-personal-customer) and [KYC/KYB Verification](/v2/docs/kyc-kyb-verification).

### Step 2 — Record Disclosures

Record the customer's acknowledgement of each required disclosure. Three are specific to this product:

| Disclosure type | Covers |
| - | - |
| `SC_ACCOUNT_AGREEMENT` | The Smart Card account agreement |
| `SC_SECURITY_AGREEMENT` | The security agreement over the linked deposit account |
| `SC_AUTO_PAYMENT` | The customer's opt-in to automatic payments, if you offer them |

Your onboarding disclosures apply as well. See [Record Disclosure Acceptance](/v2/docs/record-disclosure-acceptance).

### Step 3 — Create the Application

A charge secured account can optionally include an application, created through the Application API. See [Credit Applications](/v2/docs/credit-applications-guide).

If an application is denied — whether for KYC failure or another reason — adverse action reasons must be sent to personal customers, and the adverse action ID included when the application is marked `CREDIT_DENIED`. This is optional for business customers. See [Adverse Actions](/v2/docs/adverse-actions-guide).

### Step 4 — Create the Security Account

Create the `CHECKING` or `SAVING` account that will back the card. A customer's existing DDA can serve as the security, which is what lets them keep using those funds.

See [Using a customer DDA as a linked security account](/v2/docs/secured-sc-accounts-guide#using-a-customer-dda-as-a-linked-security-account).

We refer to the resulting account's UUID as `{SECURITY_ACCOUNT_ID}`.

### Step 5 — Create the Secured Charge Account

Create the `CHARGE_SECURED` account, pointing its `security.linked_account_id` at the deposit account from the previous step.

<CodeGroup>
  ```shell Shell theme={"system"}
  curl -X POST "$baseurl/v2/accounts" \
    -H "Authorization: Bearer $apikey" \
    -H 'Content-Type: application/json' \
    --data-binary '{
      "account_type": "CHARGE_SECURED",
      "account_template_id": "{ACCOUNT_TEMPLATE_ID}",
      "customer_id": "{CUSTOMER_ID}",
      "security": {
        "linked_account_id": "{SECURITY_ACCOUNT_ID}"
      }
    }'
  ```
</CodeGroup>

The template carries the billing period and grace period for the product. See [Creating a `CHARGE_SECURED` account](/v2/docs/secured-sc-accounts-guide#creating-a-chargesecured-account).

We refer to the resulting account's UUID as `{ACCOUNT_ID}`.

### Step 6 — Issue the Card

Issue against the charge account with `"type": "CREDIT"`, using a card product on a BIN that supports credit. Physical and virtual cards are both supported.

<CodeGroup>
  ```shell Shell theme={"system"}
  curl -X POST "$baseurl/v2/cards" \
    -H "Authorization: Bearer $apikey" \
    -H 'Content-Type: application/json' \
    --data-binary '{
      "type": "CREDIT",
      "card_details": {
        "form": "VIRTUAL",
        "account_id": "{ACCOUNT_ID}",
        "customer_id": "{CUSTOMER_ID}",
        "card_product_id": "{CARD_PRODUCT_ID}"
      }
    }'
  ```
</CodeGroup>

See [Issue a Card](/v2/docs/issue-a-card).

### Step 7 — Enable Autopay, If Offered

Autopay pays the balance from the security account so a customer who forgets does not fall delinquent. It runs only when a regular payment has **not** been received in time.

Two settings control it:

| Field | Meaning |
| - | - |
| `is_system_auto_pay_enabled` | Whether autopay runs. Defaults to `false`. |
| `auto_payment_period` | Days past the end of the billing period before autopay fires. `0` means the statement date. Maximum 28, and must not exceed `grace_period`. |

Synctera validates that `is_system_auto_pay_enabled` cannot be set to `true` unless that customer has acknowledged the `SC_AUTO_PAYMENT` disclosure. So there are two orderings:

* **Opt in during onboarding.** Record the disclosure, then create the account with `is_system_auto_pay_enabled` set to `true`.
* **Opt in later.** Create the account with the default `false`. When the customer opts in, record the disclosure, then patch the flag to `true`.

## Running the Program

### Repayment

The balance is due in full each cycle, by the date the `grace_period` sets. Payments reduce the charge account balance and release the corresponding hold on the security, restoring spending power.

### Statements

At the end of each billing cycle Synctera generates a combined statement covering both the security and the secured charge account. See [Secured Charge Statements](/v2/docs/charge-secured-statements-guide).

### Spend Controls

Spend controls apply to the charge account and limit spend by amount, window, payment type, and merchant category. See [Spend Controls](/v2/docs/spend-controls-guide).

### Disputes

Cardholders can dispute any card transaction. See [Card Transaction Disputes](/v2/docs/card-transaction-disputes).