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.
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.
Related topics
Champion / Challenger: testing a new credit policy without risking the portfolio
How to evaluate a new credit policy against the one already in production, measuring its real impact on a slice of live traffic before you adopt it.
Model riskModel risk management: governing scoring and ML models in credit decisions
Scoring and ML models sharpen credit decisions but add model risk: bias, drift, weak explainability. Govern them with validation, monitoring and audit trails.
ProductHow the uFlow decision engine does it
Governance, versioning and traceability built into the engine, without slowing the business down.
Explore all guides or read the glossary.
Would this work for your decisioning process?
Transform your credit assessment process with the decision engine.