Decision policy lifecycle

A decision policy is the rule the engine applies to the applications of a credit product: exclusions, scorecard, outcome zones and the institution's parameters. In NEXCLARA, a policy is versioned data, not code: each version is created, simulated, submitted and then approved by someone who is not its author, and it no longer changes once submitted.

States of a version

Step by step

1. Create — risk management creates a version from a reference scorecard of the product's family. The version arrives as a draft, with empty parameters: it cannot be activated as is.

2. Set parameters — the institution enters its own values: completeness threshold, product cap, target debt-service ratio, maximum term, age bounds depending on the scorecard… Each parameter declares its unit and bounds; a rate is entered as a percentage. Required parameters that are still empty are listed on screen.

3. Simulate — no version can be submitted without a simulation. Two modes open the way to submission: a fictitious test case, evaluated by the version, whose detailed calculation is shown on screen; and a replay of the product's most recently evaluated applications, within a sample limit, which counts outcomes and the applications whose outcome would change. The test case is not kept: only the simulation summary is, and it holds counts only, never an application.

   A historical simulation (Policies › “Historical simulation”) complements these two modes without changing the state of any version: it freezes a set of already evaluated applications (product, period, criteria), replays that set under a candidate version and a reference version, and returns their comparison: outcome transitions from one to the other, score distributions, exclusions and forced reviews by reason, the number of applications for which a factor changes points (never the points). The set, both versions, the engine and the results are fingerprinted; the simulation can be sealed, then reconstituted identically (“Reconstitute the simulation”). The effect on defaults is stated as “not measurable”: no credit outcome data is imported.

4. Submit — the version is frozen: definition, fingerprint and authors no longer change. An effective date can be set; it is never in the past.

5. Approve or reject — the policy approver, who is not an author of the version, approves it after a step-up verification of their second factor, or rejects it with a coded reason (inadequate parameters, insufficient simulation, inadequate effective date, other): the rejected version then returns to draft.

The rule "an author does not approve their own version" is checked twice: by the service, and by a constraint of the database itself.

Scorecard points

The points of each scorecard band are reserved for the people who design, approve or audit the policy. An analyst sees the points obtained by an application and the factors that counted, not the full scale that would let them adjust an entry.

What is still under construction

• No reason is collected at submission or approval of a version: the author and the date are recorded, the reason for the change is not yet.
• No editor for points, zones or weights: the institution sets its parameters; the structure of the reference scorecard cannot be changed from the interface.
• The simulation counts applications and outcome changes; it computes no amount and no outstanding volume.
• The comparison covers two versions replayed on the same frozen set (historical simulation); two different simulations are not compared with each other, and no constraint yet links two parameters (for example a minimum age lower than the maximum age).

See also Reference scorecards and Decision engine.