uflow
Bulk processing

Batch credit evaluation: portfolio re-scoring and pre-approval campaigns

Run the same credit policy across thousands of customers at once: pre-approval campaigns, portfolio re-scoring and backtesting, with no engineering project.

Updated July 2026 · 6 min read

In short

Batch evaluation runs the same origination policy across thousands of customers at once: pre-approval campaigns, portfolio re-scoring and backtesting. You upload a file, validate it, execute with controlled parallelism, and export the full result.

The same credit policy that decides a live application can run across your entire portfolio in a single pass. That capability — batch evaluation — turns the decision engine into a commercial and risk-management tool, not just an origination one.

Written bySantiago Etchegoyen · CTO at uFlow

CTO at uFlow. Responsible for the decision engine's architecture: API integration, orchestration of credit bureaus and data sources, running models in production, and platform security.

Use cases: far more than loan origination

When evaluating ten thousand customers costs no more than preparing a file, uses open up that previously required a dedicated engineering project:

  • Pre-approval campaigns: run the policy over your customer base and go to market with the amount and credit limit already calculated.
  • Periodic portfolio re-scoring: re-rate active customers to manage credit limits and raise early-stage delinquency alerts.
  • Backtesting: execute a candidate policy over historical credit applications and compare it against what was actually decided at the time.
  • Migrations: when replacing a policy, run both over the same base and quantify the impact before the switch.

How a batch process works inside the decision engine

The full cycle can be resolved inside the platform: you upload the input file in the files section, choose the target policy, and the process validates the content with a preview before running anything.

During execution, the level of parallelism is adjusted within the limits defined for the installation, and the dashboard shows progress with success and failure statistics plus per-query detail. When it finishes, the result is exported with the fields authorized and configured by the institution.

Best practices for running batch jobs

A batch job is one credit policy executing thousands of times: the same care you take in production applies, multiplied.

  • The file must match the names and types of the policy input variables exactly — that is what the upfront validation is there for.
  • Test with a small sample first and review the results before releasing the full base.
  • Watch your external data sources: a batch job that queries credit bureaus pays for every query. Designing the policy with a re-query window and early rules saves money here too.
  • Split very large files and tune the number of threads to the capacity of the providers being queried.
  • Download and archive the results as soon as the process completes.

Batch and real time: one policy, two speeds

The quiet value of running batch inside the decision engine is consistency: the pre-approval campaign uses exactly the same logic, versioned and audited, as live loan origination. There are not two implementations that can drift apart.

And every batch evaluation is recorded as a transaction, just like an individual credit application: the pre-approved offer made during the campaign can be reconstructed and explained, both to the customer and to the regulator.

The practices described here should be adapted to the regulations, credit policies, and consumer protection and personal data obligations that apply in each country.

Technical documentation

How this is implemented in the engine, step by step.

Frequently asked questions

Common questions

Does a batch job query the credit bureaus?+

Yes: the policy runs end to end, data sources included. That is why you should estimate the cost per query before launching, take advantage of the re-query window, and validate with a sample first. For pure backtesting, you can use a variant of the policy that reads already-stored data.

What file size should we process at a time?+

The recommended practice is to split very large files into waves and tune the number of threads to the providers being queried. The practical limit is usually not the decision engine but the rate limits and cost of the external data sources.

Would this work for your decisioning process?

Transform your credit assessment process with the decision engine.