Point-of-sale appliance finance decisions in one call
First payment default can start with a stolen identity or goods that never moved. Decisimo runs identity, device, shop and applicant checks in one call.
What goes wrong at the appliance counter
Stolen identity
A name and document used by someone else
First payment default
Loss begins before repayment becomes a credit issue
Goods never moved
The application came from a phone away from the shop
Uneven shop losses
Losses vary across the retail network
Retail partners
Shops connect the lender with appliance buyers
At the counter
The customer is still at the till
The decision at the counter, from application to reason
Application arrives
Three lookups
Identity check
Device distance
Store record
Applicant assessment
Point of sale decision
One call keeps four answers separate
- Parallel lookupsDecisimo waits for the slowest response, not their combined time
- Separate inputsIdentity, device position, store record and applicant assessment stay distinct
- Decision reasonA matching row names its deciding input, or refers the application to a person
Identity is settled before either scorecard runs
- Hard identity checksA sanctions or PEP match, missing or expired document, or name mismatch
- Identity outcomeThe rule set records whether identity is settled and gives a plain reason
- Match strengthThe applicant scorecard awards points for how strongly identity matched
Phone-to-shop distance, computed and banded
- Engine formulaAn editor-built formula uses four coordinates. No map service is called
- Position bandsPass at 200m, refer to 1,000m, decline past. Photo: 600m/3,000m
- One of fourApp delivery skips distance. It is one input, never proof on its own
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, not a verdict
- Lender’s own recordsFour measures cover defaults, distance bands, tenure and trading hours
- Default carries weightThe shop’s own default rate carries 55 of 100 points
- Second identity checkA low score refers for a second identity check. No row declines by shop
How the risk team changes a band or rule
- RevisionsEach save records a revision. Compare two releases
- Test and replaySaved cases rerun. Impact analysis shows which past decisions would move
- Release and sign-offDeploy a release to an endpoint. Sign-off can be required first
A decline at the counter carries obligations
- EU AI ActCreditworthiness is Annex III high-risk from 2 December 2027
- GDPR Article 22A declined applicant has the right to human intervention and a meaningful explanation
- Decision recordsEvery row gives a reason. Inputs and outputs can go to the lender’s own Postgres
What stays with the lender
- Demo caseEvery threshold, band and shop shown belongs to a demo case
- Lender’s policyThe policy runs on lender data. The lender decides who gets credit
- Rare merchant-assisted fraudA low shop score brings a second identity check, never exclusion
Questions we get asked
Can a shop’s record decline an appliance finance application?
A shop score can refer an application for a second identity check. No row declines it because of the shop.
Does distance from the shop decide an application by itself?
Distance is one of four inputs to the final decision. It never proves anything on its own.
What happens when someone buys in the app for home delivery?
That channel has its own row, so the phone’s distance from the shop is not assessed.
Can this decision run inside a partner’s online checkout?
The same decision flow can run inside a partner’s online checkout. See embedded finance