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

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

Overview

Key Concepts

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.

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.

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.

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.

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.

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.

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.

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

Step 1 — Create and Verify the Customer

Create the person and complete KYC. See Create a Personal Customer and 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.

Step 3 — Create the Application

A charge secured account can optionally include an application, created through the Application API. See Credit Applications.

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.

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.

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.

Shell

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}"
    }
  }'

The template carries the billing period and grace period for the product. See Creating a CHARGE_SECURED 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.

Shell

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}"
    }
  }'

See 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.

Spend Controls

Spend controls apply to the charge account and limit spend by amount, window, payment type, and merchant category. See Spend Controls.

Disputes

Cardholders can dispute any card transaction. See Card Transaction Disputes.