Setup for Galileo Secured Credit
When setting up a Galileo's Secured Credit product, you must work with the sponsor bank and card network to create a business plan that meets bank and network requirements. This guide describes considerations for Galileo Secured Credit product.
Obtaining bank and network approval
Before you can offer a secured credit product, you must get a sponsoring bank. The bank that holds your customer accounts may not sponsor secured credit. If this is the case, you will need to use a separate sponsor bank for secured credit.
When you set up a secured credit product, you are adding a new program with new BINs. You will need approval for the new BINs from both your sponsor bank and from the card network. From the card networks’ perspective, the card behaves more like a DDA than revolving credit, so it is important to be clear about why you want a credit BIN. You can ask your Galileo representative to help you with your conversation with the network to avoid misunderstandings.
Underwriting and cardholder qualifications
Galileo does not provide underwriting. You must partner with a third-party underwriter to insure the accounts and to determine what qualifications a cardholder must have, such as minimum FICO score and minimum age.
Fees and interest
If you decide to set up fees for your Galileo Secured Credit product, you determine what kinds of fees to assess, the fee amounts, and when and how to assess them. For secured credit products, Galileo supports either monthly or annual fee assessment with the Assess Fee endpoint. Your Galileo representative can help you set up fee types for your program.
If you charge interest, you will need to calculate the amount and assess it from your own system. While there is a pending dispute on an account, you are responsible for stopping the accrual of interest and for adjusting the stoppage when the dispute is resolved.
Authorized users
Galileo offers the option of adding authorized users to a primary cardholder's secured credit accounts.
An authorized user is allowed to use another person's credit card but is not liable for the debt or payment of the card. It is a useful way for someone other than the primary cardholder to build credit and have access to a credit card without the full responsibility of owning one.
Key points for authorized users:
- Access to a credit card — An authorized user receives a card with their name on it, linked to the primary secured credit account.
- Shared credit limit — They can make purchases up to the account's credit limit. Purchases for both the primary and authorized cardholders draw from the same credit limit.
- No payment obligation — The primary cardholder is responsible for making payments.
- Credit building — Being an authorized user can help build or improve the user's credit score, provided the account is in good standing.
- Only reportable authorized users are subject to credit reporting.
Note
Dynamic funding secured-credit model does not apply to authorized users.
Collateral account and money movement
For Galileo Secured Credit product, movement of funds into the collateral account is not automated by Galileo.
- The account that funds are moved from must be an account capable of holding and transferring money, such as a Galileo-hosted DDA, savings account, or an external spending account. Other types of accounts are possible as well.
- You determine when and how the cardholder can move funds into and out of the collateral account.
- You can move funds into the collateral account with a Create Account Transfer request.
- You can move funds out of the collateral account with either a Create Adjustment or a Create Payment request.
- Your sponsor bank may have conditions for allowing customers to move funds out of the collateral account.
Billing cycles
Galileo offers billing cycle configurations for consumer and corporate secured products, which can be configured at either the program or product level, according to your business plan and the agreement with your sponsor bank. All billing cycle configurations are available for credit reporting. See Configuring Billing Cycles for more information.
Enable autopay
Autopay enables your customers to pay the full balance of the previously calculated billing cycle every month through scheduled, recurring transfers. This automated process helps ensure customer’s bills are paid regularly and on time. Autopay currently only applies to secured credit and payments for the full statement amount from a qualifying Galileo account to a credit account. Galileo does not support partial payments, fixed payment amounts, or minimum payment amounts.
For secured credit accounts that have authorized users, autopay applies only to primary cardholders.
To be eligible for autopay, you must have billing cycles enabled so Galileo knows when a payment is due and for what amount. You also must be integrated with the Events API to receive autopay-related events.
For information on implementing autopay in your system, see Enabling autopay in Developer Setup for Galileo Secured Credit.
Enable semi-secured credit
Unlike Secured Credit where the credit limit is determined by the collateral balance, semi-secured credit offers a larger credit line. In this model, the customer has two Galileo-hosted accounts: a secured deposit account which holds the collateral funds and a credit account with a credit limit that is higher than the amount in the deposit account.
Semi-secured credit is only available for two and three account secured credit models.
For information on implementing semi-secured credit, see Implementing semi-secured credit in Developer Setup for Galileo Secured Credit.
Delinquency management
For secured credit products that have a charge card, Galileo determines delinquency based on the first day of the customer's billing cycle and payment rules on the account. Galileo’s delinquency management system enables you to establish predefined, automated rules to ensure timely and consistent application of your policies for handling delinquent credit accounts.
When you set up your program, you work with Galileo to configure the delinquency management in accordance with your business requirements. Your configuration should be in adherence to all applicable compliance and banking regulations, and approved by your bank partner.
Note: The selected configuration applies to all credit accounts in your program.
| Configuration | Description | Parameter |
|---|---|---|
| Bill cycle start date | Required. A value between 1 and 28 that determines the customer billing-cycle start date for all accounts in a program. For example, if the billing cycle start date is set to 1, then all accounts billing cycles start on the 1st of each month. | BRCDT |
| Grace period | Required. The number of days after the billing cycle closes when the payment is due, also known as the “due date”. Per Reg Z, this value should be no less than 21. Periodic statements must be sent at least 21 days before the payment due date, regardless of the billing cycle length. | GPD |
| Payment reminder days | Specifies the number of calendar days before the due date when payment_reminder_event is triggered.The past_due_payment_status_event is also sent 1 day before the due date if the balance remains unpaid. Only one reminder is sent if the reminders are sent on the same day.For example, if payment reminder days are set to 5, the event is triggered 5 days before the due date. | PYRD |
| Late fee grace period | Specifies the amount for the late fee applied when a payment is past due (e.g. 2.25). | LAFMT |
| Delinquency grace period | Specifies the number of days after the due date after which the account status is updated to status: Q (delinquent) if the minimum payment is unpaid.The recommended value is >30 days. Accounts are reported delinquent when a payment is late by 30 days or more after the due date. For example, if the due date is the 10th and the delinquency grace period is set to 15, the account will be marked as delinquent the 25th of the month. | DGPD |
See Galileo setup for detailed description of each parameter relevant to these configuration options.
Example
The following example is based on a billing cycle start date of the 1st of the month.
| Configuration | Value set |
|---|---|
| Billing cycle start date | 1 |
| Grace period | 4 |
| Payment reminder days | 3 |
| Late fee grace period | 5 |
| Late fee amount | 5 |
| Delinquency grace period | 12 |
- A cardholder’s billing cycle start date is set to the 1st of the month. The recent billing cycle started on November 1 and concluded on November 30 with a final balance of 150.00.
- The due date for the billing cycle was December 4 (end date of cycle + grace period).
- The
payment_reminder_eventwas sent on December 1 (due date - 3 day grace period) to inform the cardholder of the upcoming due date, and again on December 3 (due date - 1 day). - The cardholder did not pay their balance on November 30 (due date).
- As a result, a 4-day grace period was applied and a late fee of 5.00 was assessed on December 8 (due date + 5 days later as defined by the late fee grace period).
- On December 16, the account is marked delinquent (
status:Q) adhering to the 12-day delinquent grace period set during configuration. This prevents the cardholder from continuing to spend on the card until they pay the balance or debt facilitates assists with collections. See Account Statuses for details on what actions are permitted when the account is marked as delinquent.
If you have Galileo prepare a Metro 2 credit report for you, Galileo will include each delinquent account in the Metro 2 report that you send to the credit bureaus.
Collections
You define your own terms and conditions describing what occurs when a cardholder does not repay the credit line. Galileo does not automatically move funds from the secured credit account to cover the amount owed.
If needed, you may work with a debt facilitator to assist with collections. Galileo does not recommend closing the account when the cardholder defaults; instead, you should block spending on the account instead.
Credit reporting
Galileo can handle reporting only for secured credit products that operate as a charge card with the full amount due each period. There is no legal requirement to report credit account activity to the three credit bureaus. Whether you report to the credit bureaus depends on whether you believe your cardholders will benefit from it. Credit reporting applies to both primary cardholders and any reportable authorized users.
For more information on credit reporting, see the Credit Reporting at Galileo.
Chargebacks and disputes
For charge cards associated with a secured credit product, you may be able to use the same chargeback process that you have for debit cards if the card network is the same. However, you are responsible for setting up your own internal process to handle disputes for fees and interest for the secured credit product. There is no provisional credit for a charge card.
Statements and invoices
You can use RDFs and your own internal reporting to generate statements and invoices according to your agreement with your sponsoring bank. You can change the frequency of invoices depending on how far ahead you can float transactions. For example, you could have two billing cycles per month, or set up weekly billing cycles. See Configuring Billing Cycles for more information.
CST support for Galileo Secured Credit
This section describes features in the CST related to secured credit.
Billing cycles
| CST field | Location | Description |
|---|---|---|
| Next Billing Date | Account Info > Account Details > Summary Information | The customer’s next billing cycle start date. |
Galileo setup
See the Credit parameters table for details of the list of product parameters that can be configured at Galileo.
| Parameter | Description |
|---|---|
| ACSET | Controls the steps that are required for account setup during onboarding. For credit products, set this parameter to TC (Total ID (CIP) first, credit). See ACSET values for details. |
| ALWNB | Controls whether a call to the Create Adjustment endpoint can drive an account balance negative. When this parameter is set to 1, a call to the Create Adjustment endpoint can drive the balance negative. |
| BCDAY | Controls the length of time to wait after the bill cycle start date before setting the bill cycle and assessing fees. Use an integer to specify the number of days or MONTH to indicate a one month bill cycle. |
| BRCDT | Controls the customer billing cycle date. Values for secured credit products are:ACCOUNT_DATE — Sets the billing cycle date to the day that the account is created. If an account is created on day 29, 30, or 31, then the billing cycle date is 28. Yields 28 possible billing cycle dates. 1, 8, 16, 24 — Sets the billing cycle date based on the week that the account is created. Possible dates are 1, 8, 16, and 24. Yields four possible billing cycle dates. |
| CYCLE | Controls whether to assess maintenance fees monthly (MON) or yearly (YER). Weekly assessment is not available for secured credit products. Works in conjunction with CYMET. |
| CYDAY | Specifies the day of the month to assess fees when CYCLE is set to MON. Valid values are 1–28. Weekly assessment is not available for secured credit products. |
| CYMET | Controls whether to assess a fee by account (PRN) or balance (bal_id). This parameter also controls what happens if the balance is lower than the fee amount. Values for secured credit products are:A — Set an independent bill cycle for each account and assess fees by account.B — Set the same bill cycle for all accounts on the same balance and assess fees by balance.HAD — Hybrid account. Assess fees by account and defer the fee if it will drive the balance negative.HAP — Hybrid account. Assess fees by account and charge a partial fee if the entire fee will drive the balance negative. This effectively takes the balance to 0.HBD — Hybrid account. Assess fees by balance and defer the fee if it will drive the balance negative.HBP — Hybrid account. Assess fees by balance and charge a partial fee if the entire fee will drive the balance negative. |
| DGPD | The number of days after the due date when the account status is changed to status: Q (delinquent) if the minimum payment is unpaid. |
| GPD | The number of days after the billing cycle closes when the payment is due, also known as the due date (cycle close date + grace period date.) |
| LAFMT | The fixed late fee amount assessed on past due accounts. Leverages the LAT(0001) fee type. |
| LFGP | Days after the due date when a late fee is assessed if the minimum payment is not made. |
| PYRD | Number of days before the due date when a payment reminder event is triggered. |
Updated about 3 hours ago