Prevoyance IT Solutions for Satin FinServe
A credit decision you can
defend line by line
Documents are read by a model that runs inside Satin's own network. The decision itself is made by a deterministic rule engine, so the same file and the same policy produce the same answer every time, and every approve, refer and decline carries the reason code that produced it.
Access by desk
Open a case, add the document set, and review what the engine read across seven profile sections. Correct any field and the decision recomputes from the corrected file.
Sign in Sanctioning and AdministrationRecord the final approve or deny under four eyes, with a written reason on any departure from the engine. Manage users and queues, and pull the audit exports.
Sign inHow this engine is built
The decision is deterministic
Policy gates, then a weighted scorecard to a grade and a probability of default, then a decision matrix that sets the amount and the price. No model chooses the outcome, so an auditor can recompute it by hand.
Every outcome carries its reason
Approve, refer and decline each carry codes from a maintained dictionary. The answer to why an application was declined is a named rule, not a score without an explanation.
Corrections recompute, they never patch
Editing a field appends a new version of the profile and a new assessment. The earlier decision stays readable beside the one that replaced it, so the change is inspectable.
A ledger that shows tampering
Every extraction, correction, decision and sign-off is hash chained to the entry before it. Altering history breaks the chain from that point onward, and the break is detectable.
Policy sits in configuration
Thresholds, weights, grades and pricing live in versioned configuration. A credit policy manager retunes a product without a code release, and each decision records the exact configuration it ran against.
Satin's infrastructure, Satin's documents
The model that reads the file runs on Satin's own servers. Borrower documents are not sent to a third party service to be understood.
The engine at a glance
- Stage 1ReadOptical capture and a locally hosted model turn the document set into a structured profile, each field carrying its confidence.
- Stage 2VerifyCross checks across the extracted fields raise flags rather than passing a discrepancy silently.
- Stage 3DeriveObligation ratio, loan to value, instalment, bounce counts and income consistency, computed and reproducible.
- Stage 4DecidePolicy gates, weighted scorecard, grade and probability of default, then amount and risk based price.
- Stage 5ReviewThe underwriter reads the whole profile, corrects what was misread, and the file recomputes.
- Stage 6DisposeRecommendation and final decision are recorded by two different people, with a reason on any override.
Sign in to open a live case and follow it from the queue through to sanction.
Sign in