Four answers for appliance finance at the till
A first payment default can start with stolen identity or goods that never moved. One call separates identity, shop presence, store record and applicant assessment at the counter.
Identitysettled
Devicelocation
Storerecord
Applicantscore
One decision flow, four answers
The final decision can show which part of the application determined the outcome, from identity to the store record held on your own book.
Settle identity first
A rule set checks four hard facts before either scorecard runs: sanctions or PEP match, missing document, expired document or a name mismatch.
Check where the device was
A custom function computes the distance between the phone and the named shop. A decision table sends the result to approval, human review or decline by band.
Read your store record
A scorecard uses your own records for the shop, including first payment default and applications taken outside the distance band.
Keep the applicant assessment distinct
A second scorecard assesses the applicant. The final decision table sees its points alongside identity, device location and the store record.
What runs in the one decision call
The flow joins its lookups to identity rules and both scorecards before the final decision table writes its reason.
- Three lookups run together. Identity verification and bureau data run alongside your store record service on one part of the decision flow. It finishes when the slowest lookup finishes.
- Identity is settled before scoring. The identity gate writes whether identity is settled. It does not make the decline, so the final decision still considers the other inputs.
- Every outcome carries a reason. Each outcome row names which of the four decision inputs determined the result. An unmatched policy row goes to a person.
- Connect the wider credit lifecycle. Affordability and the rest of the credit lifecycle belong with consumer lending decisions, not in this point-of-sale check.
Compute distance, then use a presence band
The distance calculation gives the lender a graded presence signal that respects the channel and the source of the position.
The engine computes the distance between the phone position on the application and the shop position in the store record. A custom function uses the haversine formula in metres. No map service or provider is called.
Distance is a band, not a yes-or-no proof. App positions get a 200 metre inner band and a one kilometre outer band. Photo metadata gets a 600 metre inner band and a three kilometre outer band because it is coarser. At the shop, the application passes. Near the shop, it goes to a person; away from the shop, it declines. An in-store application with no device position also goes to a person. An app purchase for delivery uses a separate channel row because the phone should be at home.
Ask for the calculation in plain language
Watch the assistant build the distance check from a plain-language request, then see a person review and approve it before anything is created.
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.
Use your store record, not a merchant verdict
The store scorecard turns four columns from your own distribution records into a route for the next identity check.
- First payment default. A shop’s default rate over the last twelve months carries more than half the points. It is the strongest signal in the store record.
- Applications outside the distance band. This share shows how often recent applications placed the device outside the expected distance band, adding location context to the shop’s record.
- Time on programme. Months on the programme show how much history the lender has for that shop. A newer shop has less history in the lender’s own book.
- Applications outside trading hours. This share shows how often applications were taken outside trading hours, adding an operational pattern from records the lender already holds.
A second check is not a merchant verdict
The four columns are arithmetic on the lender’s own book about its own distribution. They are not a third-party rating, and the worst band does not turn a shop off or decline an application.
Merchant-assisted fraud is real and rare. The design answers with a second identity check because the worst band still contains far more paying customers than defaults. It does not label a merchant or its staff as dishonest.
Evidence for governed credit decisions
Assessing a person’s creditworthiness is named as high-risk in Annex III of the EU AI Act, with those obligations applying from 2 December 2027. GDPR Article 22 gives a declined applicant the right to human intervention and a meaningful explanation. See the governance controls for the obligations and evidence.
Questions we get asked
Does the store score decline an application?
No. The store scorecard’s worst band routes the application to a second identity check. The final decision table has no row that declines because of the shop.
What does the identity gate decide?
It writes whether identity is settled. The rule set checks a sanctions or PEP match, document presence, document expiry and name matching. It runs before either scorecard and does not make the decline itself.
Can distance from the shop decide the outcome on its own?
No. Distance is banded into a presence result. The final decision table considers that result with identity, the store record points and the applicant assessment points.
How does an app delivery differ from an in-store application?
The presence table has a channel condition. An appliance bought in the app for delivery expects the phone at home, so that case uses a separate row rather than failing an in-store distance check.
Where are execution traces kept?
Execution traces live on the customer’s side, in infrastructure the customer controls. Decisimo keeps the decision logic and its revision history, plus the platform audit log of portal actions.
Can a risk analyst change a threshold?
Yes. The analyst changes it in the portal, runs the regression suite and reads the impact analysis. The change then goes through approval and reaches production as a release; the difference between releases is computed.
Does this also cover decisions that wait for evidence?
This flow sends an unmatched policy row to a person. Decisions that wait on a person or evidence are handled as a case file in case work. If the call runs inside a partner checkout, see embedded finance.
See the appliance finance flow
Bring your point-of-sale inputs and see how the four decisions can be separated in one flow.