Change limits by file

Use a file when the new limits are already calculated: a model ran outside the platform, the commercial team agreed a list, or you are correcting a set of lines one by one. The file says which customer gets which limit; the screen checks every row, shows you the impact, and creates a batch.

To start, open Modify Limits › Manual adjustment and, on the Upload file with changes card, click Upload file. The flow has two steps, Upload and Review.

The file

The file can be CSV or XLSX, with one row per customer. Download Example Template gives you a spreadsheet with the right headers and a sample row; it is the safest starting point.

The file needs the customer column and at least one of Credit Limit or Credit Enabled. Within those columns, a blank cell means "leave this as it is". A row with no Credit Limit keeps its current limit, and a row with no Credit Enabled keeps its current status, so a file can change only limits, only statuses, or both. The limit cannot be zero: to stop a customer from using their line, set Credit Enabled to No.

An example with fictitious data:

Here the first customer gets a new limit and moves to the Premium segment, the second only gets a new limit, the third is disabled without touching the limit, and the fourth gets a new limit and a segment while keeping its current status.

The customer identifier

The Customer identifier selector tells the platform what the values in Customer ID are: a tax ID, a national ID, or any other identity your organization stores. It comes preselected with the identity your organization uses to link customers to their credit lines, which is the right choice for most files.

Whatever you select, a row also matches if its value is the customer's AltScore ID or their external ID, so a file built from an export of the platform works as is. If one value belongs to more than one customer for the selected identity, that row is rejected rather than guessed.

When you choose an identity, the template uses its name as the header of the first column, and the upload accepts that header too.

The Segment column

Segment places each customer in a segment as part of the same batch. It only works if your organization has defined which customer category holds its segments; otherwise the column is ignored and the limits still apply.

A segment name that does not exist yet is created as soon as you confirm the batch, even if the batch is later discarded. Because a typo looks exactly like a new segment, the review step lists every new name with the rows where it appears, so you can catch Premiun next to Premium before anything is written.

Upload and validation

On the upload step, fill in:

• Label (required), which is how you will find the batch later, for example Quarterly adjustment Q1.
• Description, an optional note.
• Customer identifier and the file.
• Guardrails and Validity, described below. Set them before validating, because the review numbers are calculated with them.

Then click Validate File. Validation reads every row and compares it with the current state of each line. It usually takes seconds, more for very large files.

If neither the limit nor the status column is recognized, the screen asks you to match them: Review Column Mapping shows each column of your file and lets you assign it to Customer ID, Credit Limit or Credit Enabled. If the customer column's header is not recognized, the first unrecognized column is taken as the customer ID, so check that it is the right one.

If any row has an error, the file is rejected as a whole and nothing is created. The screen shows how many rows failed for each reason, and Download Error Report gives you the file back with the problem marked on each row. Fix those rows and upload again.

Some findings do not reject the file. A customer who does not have a credit line yet gets one created when the batch is applied, and the screen warns you how many. A customer that was archived, usually because it was merged into another one, is skipped. A blank or unusable segment name keeps the customer's current segment while the limit still applies.

Guardrails

Guardrails are limits on the result, applied to every row after the file is read.

• Limit floor: no limit ends up below this value. A row asking for less is raised to the floor.
• Limit ceiling: no limit ends up above this value. A row asking for more is lowered to the ceiling.
• Keep disabled lines disabled: when on, a line that is currently disabled keeps its current limit, whatever the file says.

Leave the floor or the ceiling empty for no bound. The review step tells you how many rows each guardrail adjusted, and the batch keeps the guardrails it was created with, so anyone opening it later can see them.

Review

When validation passes, the screen moves to Review. On the left are the details you entered and the guardrails and validity that apply. On the right are three blocks that tell you what the batch will do.

Impact compares before and after for the lines in the file: Total Exposure (the sum of their limits), Average Limit and Maximum. The percentage next to total exposure is the overall change, green when it grows and red when it shrinks.

Distribution splits the rows by what happens to them: Increase and Decrease for rows whose limit goes up or down, Enable for disabled lines the file turns on, and Disable for rows that set the line to disabled, including lines that already are. A row is counted once, in the first category that applies, in this order: disabled, enabled, increased, decreased.

Change Summary gives the number of rows in the file and how many of them actually change something, for example 150 of 160 change the limit or the status. If no row changes anything, because every limit in the file is the one the line already has, the screen says so: No row changes anything: every one repeats the limit it already has. Below that, it lists how many disabled lines will be enabled and how many rows the floor or ceiling adjusted.

Read the summary before confirming. A large drop in total exposure with every row a decrease is worth a second look: check that the limit column was mapped correctly and that the values are in the column you expect.

Create or apply

At the bottom of the review there is a checkbox, Apply changes immediately, and the confirm button changes with it.

• Unchecked, the button reads Create recommendation. The batch is created and waits in the Recommendations tab with status To review, where you or a colleague can open it, adjust lines and apply it. This is the right choice when someone else signs off.
• Checked, the button reads Confirm and apply. The batch is created and applied as soon as its lines are prepared, provided none of them failed. If any did, it waits as To review with errors.

Either way you go back to the Limits screen, and you can follow the batch from its detail page. See Tracking a batch.

If you set an activation date in Validity, the batch waits for that date and applies on its own, whether or not the checkbox is ticked. See Temporary changes.

What applying does

For each line, applying writes the new limit, then changes the enabled or disabled status if the file asked for a status different from the current one, then places the customer in the new segment if there is one. The limit is written in the currency configured for your organization's credit product; the file has no currency column.

Each line is applied on its own. If some lines fail, the rest are still applied, and the batch ends as Completed with errors with the failed lines listed and a way to retry them.