Appliance finance decisions at the counter

First payment default can begin with a stolen identity at a counter or goods that never moved. Decisimo runs the lender's checks in one decision flow and records the reason for the point of sale decision.

Start free See the decision flow

One decision flow keeps four answers apart

Application checks calls three lookups at the same time and waits as long as the slowest one. Identity, where the device was, the store record and the applicant assessment remain separate stages before the final decision table names which one of the four decided. Every threshold, band and store in the screenshots and video belongs to a demo case.

Flow shows Application checks, Identity gate, device location, Store record, Applicant assessment and Point of sale decision
The canvas shows the Appliance finance at the till decision flow from application checks to the point of sale decision. The risk team can keep identity, device presence, the store record and applicant assessment distinct in one call.

Identity is settled before either scorecard runs

The rule set knocks out on a sanctions or PEP match, no identity document, an expired document or a name mismatch. It writes whether identity is settled, while the final table makes the decline. Match strength earns points in the applicant scorecard, so the same evidence is not counted twice.

Identity gate rule set shows a sanctions or PEP hit setting identity as unsettled and recording the reason
The Identity gate screen shows the hard facts that prevent identity from being settled. The risk team gets a plain-language reason before the point of sale decision uses the result.

The engine computes distance and bands the result

The engine computes distance from coordinates already held by the lender, using a formula built in an editor with no map service or provider called. For an app position, up to 200 metres passes and up to 1000 metres goes to a person; photo metadata uses wider bands of 600 and 3000 metres because it is coarser. An app purchase for delivery has its own row, so distance is not assessed. Distance is one of four inputs; it does not prove anything on its own.

Distance decision table shows app GPS bands at 200/1000 m and photo metadata bands at 600/3000 m
This table shows the bands for device position by channel and source. The risk team can send a near-store result to a person and keep delivery applications on their own row.

Ask the assistant for a distance check in plain language

The assistant plans and builds the check from a plain-language request, then a person reads the proposal before anything changes.

Transcript

A customer asks to pay for a camera in instalments, and the application says they are standing at the till, in this shop in Zamalek.

They are not. The phone that sent that application is nine kilometres away, on the other side of the Nile.

That position is not something a customer types in. It comes from the app on the phone, or from the photo of the goods.

Because a photo records where and when it was taken, inside the file. One taken at home says so.

So a risk team can write the policy in metres. Inside two hundred, the customer is where they say they are. Up to a kilometre, a person looks. Past that, decline.

Distance is one signal among several. A phone can lie about where it is, and a shopper can be out in the car park, which is what the middle band is for.

All of it is already in the application: the shop’s position from your own records, the phone’s from the app or the photo.

So ask for the check the way a risk officer would say it out loud. No formula, and no external service to call.

It plans two pieces before it builds anything. Something to calculate the distance, then something to decide on it.

And it writes the calculation itself, out of the four coordinates the application already carries.

Degrees converted to radians, then the haversine formula, on an Earth radius in metres. Four coordinates in, one distance out.

Every term in it points at a field in your own data, so nothing is typed in twice and nothing drifts.

Test it on its own, before any of it decides anything. Forty three metres from inside the shop.

Then the table decides, with the policy written into the rows exactly as the risk team said it.

And when the rule needs to change, describe the change. A location read off a photo is coarser than the app’s own, so the bands around it should be wider.

It comes back as a proposal. Your team reads the change and approves it before anything goes live.

Now the same distance is read two ways, by where the location came from.

End to end, on real applications. The one from inside the shop goes through.

And the one from across the river is declined, with the distance and the reason on the record.

Decisimo. Decision logic that’s easy to connect, and easy to change.

The lender's shop record is an input, never a verdict

The scorecard uses first payment default, the share of applications outside the distance band, months on the programme and the share taken outside trading hours. Each measure is arithmetic on the lender's own distribution records, so none is a third-party rating or an allegation. The shop's own default rate carries 55 of the 100 points; a low store record score refers the application for a second identity check, and no row declines because of the shop. Merchant-assisted fraud is rare, so the policy uses a second identity check.

Store record scorecard showing predictor bins, score values and weights for defaults, distance, programme length and hours
This scorecard shows how the lender's own shop records contribute points. The risk team can use a low store record score to refer an application for a second identity check.

A decline at the counter is a credit decision with obligations

Assessing the creditworthiness of a person is an Annex III high-risk use under the EU AI Act; those obligations apply from 2 December 2027. GDPR Article 22 gives a declined applicant the right to human intervention and a meaningful explanation. Each row's reason and each decision's input and output can be written to the customer's own Postgres database; governance covers the obligations.

Questions we get asked

Can a shop’s record decline an application?

A low store record score refers the application for a second identity check. The final table considers the store record with identity, device presence and applicant assessment. No row declines an application because of the shop.

Does distance from the shop decide the outcome by itself?

Distance is one input among four in the final point of sale decision. The table bands a position from the app or photo metadata, and a nearby position goes to a person.

How is an app purchase for home delivery treated?

An app purchase for delivery has its own row in the device position table. The policy does not assess distance for that row.

How can a risk analyst change a band and see its effect first?

A risk analyst can compare revisions, rerun saved test cases and use impact analysis to replay past decisions. Sign-off applies when the endpoint requires it before a release is deployed.

What happens when no policy row matches an application?

An application that matches no policy row is referred to a person. Decisions that wait on a person or evidence can be worked as a case in case management.

Can the same decision run inside a partner’s online checkout?

The same decision can run inside a partner's online checkout. See embedded finance for decisions inside a partner's online journey.

Build the decision flow your counter needs

Start with your own identity, device position, shop and applicant inputs, then run the decision flow through your endpoint.

Start free