Setup terms control key account timing defaults, like when the account opens, when statements start, and how long customers have to make a payment. These values apply when the account is first created, existing accounts won’t be affected if you make changes later. 

Here's a breakdown of the available options:

• Open date. Determines when the account becomes active and available to the customer. Options include the same day as the account is created or a custom date, which can be offset by a specific number of days.
• First statement date. Sets the number of days between the Open Date and when the first statement is generated. You can specify any number of days (e.g., 30 days) to control this timing.
• Due dates and grace period. Sets the number of days between the statement date and the payment due date for each billing cycle. This value effectively determines the grace period between when a bill is issued and when it must be paid. 
• Frequency. Controls how often statements are generated and payments are due. Options include monthly, bi-weekly, semi-monthly, and semi-monthly (alt). 
• Draw period. Defines whether an account has a set period during which new draws (or charges) are allowed. Options are:
  • Yes - You can define how long the draw period lasts. Once the period ends, new draws are no longer permitted.
  • No  - Draws can be made at any time, without restriction. 
• Overdrafts. Controls whether customers can spend beyond their credit limit, resulting in a negative available balance.  Options are:
  • Yes - Overdrafts are allowed
  • No - Spending is restricted once the available balance reaches zero. 

For example, a typical setup might open the account the same day it’s created, generate the first statement 30 days later, and set payments due 21 days after each statement. Statements might follow a monthly schedule with consistent dates each cycle. In this case, the program allows ongoing charges with no defined draw period and does not permit overdrafts.

This section lets you define how balances are grouped into categories (called buckets) and how interest is calculated for each. Transactions are assigned to these buckets based on type (e.g., swipes, fees), with each bucket applying its own rules for interest calculation.

You can also create transaction rules to automatically route new activity based on custom logic, like sending Kroger or Publix purchases into a “Groceries” bucket. 

Buckets

Buckets categorize transactions and define how interest is calculated. Each account can have multiple buckets, with one bucket designated the primary.

• Primary bucket. Select whether a bucket should serve as the primary, where uncategorized transactions are routed by default. 
• Credit limit. Set a default credit limit for transactions assigned to this bucket. 
• Computation method. Choose how interest should be calculated. Options include Average Daily Balance, Daily Balance, Previous Balance, or Adjusted Balance methods.
• New transactions. Choose when transactions start accruing interest (e.g., immediately, after grace period loss, or in the following billing cycle).
• Interest rate. Set a default interest rate, day count basis, and minimum interest charged per billing cycle. Decide whether interest charges should compound monthly. 
• Interest abatement. Suspend interest accrual either at the bucket level or for individual transactions. Choose how long abatement should apply (e.g., 30 days from account open or transaction date). 

Transaction rules

Transaction rules allow you to sort swipes and other activity into specific buckets based on transaction or account details. 

• Name. Give the rule a name to help identify its logic.
• Bucket assignment. Specify which bucket transactions should be placed in if this rule applies.
• Conditions. Use Clojure logic to define the rule’s criteria. When a transaction is created, each rule is evaluated in order until one returns true. The rule’s bucket is applied. If none apply, the transaction is routed to the primary bucket.

These options give your granular control over how balances are treated and can help you create distinct repayment experiences by product or customer segment. 

In this tab, you define how minimum payments are calculated at the end of each billing cycle for accounts in the program. These settings are defaults, any changes will only apply to new accounts going forward.

You can configure: 

• General calculation type. Choose whether the minimum payment should be:
  • The lesser of a percentage of the statement balance or a fixed dollar amount
  • The greater of the two
  • A sum of the two (percentage plus a static dollar amount)
• Percentage of statement balance. Enter the percentage to use and specify whether certain categories (like outstanding fees, current-period interest, or abated swipes) should be excluded from the balance before the percentage is applied.
• Static dollar amount. Set the fallback amount for the minimum due, depending on the calculation type selected. 
• Added amounts. You have the option to include certain transaction types in both the percentage and static dollar calculations before the system determines which is used.
• Rounding rules. You can round the minimum payment to the nearest $5, $10, or other set amount to keep payment amounts clean. Choose from three methods: standard rounding (rounds up at halfway), always round up, or always round down. Then choose the rounding interval (e.g., nearest $5.00).

For example, if a customer’s balance is $2,000, and you’ve set a static amount at $30 and the percentage at 2.5%, the percentage would yield $50. If you’re using a “lesser of” rule, $30 would be used instead.

Define how late fees should be calculated and whether they should accrue interest. 

• General calculation type. Choose how to calculate the fee:
  • A fixed dollar amount
  • A percentage of the unpaid portion of the missed payment
  • The lesser of those two
  • Or the greater of the two
• Percentage of missed payment. Set the percentage to use. This is based only on the amount still unpaid. For example, if the minimum due was $30 and $10 was paid, the fee would be based on the remaining $20. 
• Static amount. Enter the flat dollar amount used in the calculation (when applicable).
• Interest accrual. Choose whether late fees should accrue interest, using the same rules described in Fee Defaults. 

This section determines which statement template is assigned to accounts by default when they’re created. The select template controls how billing statements look and what information they include.

If you need to update the actual content or layout of the template itself, you’ll do that in the Statements section under Settings > Line of Credit. 

• Default statement template. Choose the template that should be used for accounts in this program by default.

If the product you’re creating issues cards, this section determines how those cards are handled by default.

Settings in this section include:

• Card issuance. Decide whether cards are issued automatically when accounts are created.
• Cash advances. Select which bucket to route cash advance transactions.
• Card program. Determine which card program is used by default in Secure Payments.

These settings help ensure cards are consistently issued and managed.

Rollovers & linking lets you connect multiple credit lines or loans to a main account. It’s helpful when you want to organize related accounts together and customize how available credit is calculated.

Settings in this section include:

• Rollovers & linking permissions. Set whether linking and rollover behavior is allowed.
• Available credit impact. Decide how linked accounts impact the main account’s available credit
  • For loans: Choose between principal or payoff balance.
  • For credit lines: The general balance is always used.
• Credit limit impact. Determine whether linked credit lines can increase the main account’s credit limit.
• Default linked bucket. Select which bucket a linked account's balance will apply to by default.

When a loan is linked, you can choose whether the principal balance or payoff amount is used to reduce the available credit of the main account. 

Guardrail groups allow you to define internal validation rules that limit what actions can be taken on an account, whether by servicing agents or through the API. These are typically used to enforce business policies or meet compliance requirements.

Each rule includes:

• The field or action the rule applies to
• Logic that determines when the rule triggers
• A validation type (a warning or error message to be shown to the agent)
• A message shown to the agent when the rule triggers

For example, you might configure a rule that warns agents when increasing a borrower’s credit limit without verifying their ability to repay, referencing the CARD Act directly in the message.

Guardrails are applied in real-time and help standardize servicing behavior across teams. 

Dispute defaults control how provisional credits, chargebacks, and write-offs are handled when disputes are logged on accounts in a program. These settings determine how credits work, how they’re allocated, and whether they affect delinquency status.

Provision credits

Provision credits are temporary credit issued during a dispute investigation to give the customer short-term relief. In this section, you’ll define how the credit is categorized, how it’s applied, and whether it affects delinquency. 

• Choose the default credit type to use (i.e., Promo Credit, Forgive Credit, Charge-off).
• Select how the credit should be allocated across balances: Regular or interest only.
• Define how credits apply toward the minimum payment.
• Decide whether provisional credits should reduce delinquency on the account.

Chargebacks & write-offs

Chargebacks and write-offs are final credits issued when a dispute is resolved in the customer’s favor, either assigning liability to the merchant (chargeback) or issuer (write-off). Here, you’ll define how credits are applied when a dispute is closed in the customer’s favor.

• Set the credit type to use for chargebacks and write-offs.
• Choose the allocation method: Regular or interest only.
• Determine whether these credits should reduce delinquency or simply adjust balances without affecting the account’s status.

These values help standardize how new accounts are set up, like assigning an initial status, selecting credit reporting codes, and determining payment preferences. They only apply when the account is created.

Defaults fall into three main categories:

Account settings

Controls the operational attributes assigned to accounts by default.

For account settings, you can configure:

• Account status & substatus. Choose which lifecycle status (e.g., Open, Application, Closed) and specific substatus (e.g., Application - Manual Review) accounts in this program should start with. 
• Agent user. Assign a default servicing agent, if applicable. 
• Source tracking. Tag accounts with a default origin source.
• Portfolios. Select one or more portfolios and sub-portfolios to group accounts by.
• Date fields. You can choose to assign default dates for repossession, liquidation, closure, or follow-up.

Credit reporting

Specifies how accounts should be reported to credit bureaus.

Settings in this section include:

• Credit status. Sets the default credit status (e.g., current, delinquent, bankruptcy) for reporting. 
• Reporting type. Determines whether the account is reported as a line of credit, installment loan, etc.
• Credit bureau account type. Maps the account to a standardized bureau type, like credit card or auto loan. 
• Primary & secondary ECOA codes. Assign default ECOA relationship codes for primary and secondary customers (e.g., Individual).

Billing & payments

Defines how accounts handle e-billing, payment types, and Autopay status.

Here’s a breakdown:

• E-billing. Choose whether accounts default to receiving paperless statements.
• Merchant processor group. Assign a group that helps determine which payment processor is used for transactions, based on the direction of funds and payment method.
• Payment type default. Set the default payment type, which determines the order in which funds are applied to interest, fees, and principal.
• AutoPay status. Determine whether AutoPays are allowed to process by default. This won’t prevent AutoPays from being created, only from processing.

These defaults make it easier to set up accounts consistently, while still always allowing for manual override on individual accounts when needed. 

Payment settings control how both one-time (manual) payments and recurring (Autopay) payments behave by default. These defaults apply to accounts created in this program and help standardize how funds are collected and processed.

Manual payments

Manual payment settings apply to one-time payments that are not processed through Autopay.

For manual payments, you can configure:

• Payment type. Choose how payments are applied. For example, as a regular payment (covering all balances) or interest-only. 
• Payment method and profile. Set the default payment profile to use when processing payments, such as the primary customer’s bank account. You can also choose a fallback method (e.g., cash, check, EFT) if no payment profile is used. 
• Authorization type. If bank accounts are used, select default ACH authorization (e.g., PPD, TEL, WEB) required for processing. 
• Payment splitting. If the account is linked to other accounts, you can choose to split incoming payments across them. Splits prioritize past-due balances first using the Due Amounts method. '
• Convenience fee. Choose whether to apply a fee to one-time payment processed through a payment processor.

AutoPay

AutoPay settings determine how recurring payments are created, scheduled, and processed. 

For AutoPays, you can configure:

• Process timing. Set the time of day AutoPays should run and whether they should skip weekends or holidays. 
• Autopay type. Choose the default type (e.g., recurring vs. one-time) and set a default frequency for recurring AutoPays (monthly, bi-weekly, etc.).
• Payment type. Choose whether Autopay payments apply as regular or interest-only by default. 
• Payment splitting. Just like with manual payments, AutoPays can also be split across linked accounts. 
• Special circumstances. You can choose to skip AutoPays when an account is already current, or adjust the Autopay amount if the account balance is lower than expected. 
• Rescheduling. Set how AutoPays are rescheduled if a payment fails or if timing changes. You can also choose whether to retry failed AutoPays. 
• Processing gap. Choose how many days should separate the process and apply dates, and whether that’s based on calendar or business days. 
• Convenience fee.  Decide if a fee should be charged for payments made via Autopay. 
• Dispute amounts. Choose whether to exclude disputed charges from the Autopay calculation.  

These defaults standardize how manual and automatic payments are handled across accounts in the program. You can still override any of these settings on a per-account basis as needed.

The fees section sets defaults for how manual, late, and recurring fees are created and handled across accounts in this program. These defaults apply when a fee is posted and help standardize setup across your portfolio.

Fee defaults

Set the baseline configuration for any manual fees posted to accounts in this program.

• Fee type. Choose the default fee type (i.e., late fee, NSF, etc.)
• Interest accrual. Decide whether manual fees should accrue interest. If yes, they’ll follow the interest rules of the bucket they’re placed in. If not, they’ll remain static no matter what happens with rates or missed payments.  

Recurring fees

Configure custom rules that automatically post fees to account under specific conditions.

Here’s how it work:

1. Set the name of the recurring fee and the descriptive label that will appear with posted changes.
2. Choose which fee type to use (e.g., late fee, convenience fee, NSF, etc.)
3. Decide whether the fee amount is a flat number or calculated using logic. For complex logic, write a rule in Clojure.
4. Determine whether these fees accrue interest once posted.
5. And lastly, set the trigger for when the fee is evaluated and applied. Options include:
   1. Account activation
   2. Payment reversal
   3. Swipe creation
   4. A custom trigger evaluated during daily maintenance

If an account is linked to others, this section defines how payments are split among them, based on the logic you configure. You can choose how to allocate payments based on due amounts, payment timing, and loan type.

Key split payment rules include:

• How to calculate the split (e.g., by due amount or by due date)
• Whether to include the main account in the calculation
• What payment type to apply after splitting
• How to handle extra towards amounts on linked loans (e.g., apply to principal vs. next payment)

These rules are important if you offer linked child accounts under a master line of credit or any other scenario where payment distribution matters. 

Quick Actions are one-click buttons that trigger a predefined workflow, like sending a webhook or enrolling an account in a new program. These can be permissioned by user role and made available within the agent portal.

Quick Action examples:

• Skip a payment
• Apply a rate promotion
• Enroll in a membership program
• Process an SCRA notification

Quick Actions make servicing faster, more consistent, and easier to track, especially for agent teams working across multiple programs. 

We’re continuing to expand what’s configurable through the Programs interface. In the meantime, use the Help page to quickly find where to manage account attributes, transaction types, and general platform settings across the platform.