VECTORIO
EN
EnglishDeutsch

“For actuarial teams that must show exactly how a reserve was produced”

Reproducible reserves, run in minutes.

More scenario iterations per day on workstations.

The problem
  • Actuarial models run in batch overnight; a change means waiting a day.
  • I must show supervisors exactly which data and code produced the reserve.
  • Getting customer data into a public cloud is a hard sell.
With PROTOR
  • More scenario iterations per day on workstations.
  • Reserve and pricing figures are reproducible and traceable.
  • Sensitive claims data stays in the perimeter.

From today to the first result.

What you do today

overnight batch runs for actuarial models

A model change waits a day for the next batch run, and showing the supervisor which data and code produced a reserve takes manual work.

With PROTOR

1 billion rows aggregated in 32.1 ms on a workstation, so scenarios iterate within the working day. Each reserve figure carries its data and code hash.

Your first step

Run one reserve calculation on a workstation and compare it with the batch result.

one calculation
How it runs

Transactions with an audit trail built in. Step by step.

Every transaction is hashed on the way in, out-of-range amounts go to a review table, and the sealed evidence package is re-verified independently.

PROTOR · Transactions with an audit trail built inrunning
FinancialRandomDataProviderTransaction EvidenceEvidence CollectorRow Integrity HashKey GeneratorFinancial EvidenceEvidence PackAmount Validation GateQuality GateEPK Integrity VerifierEvidence VerifierValid Transactions CSVCSV PublisherRejected TransactionsCSV Publisher
  1. FinancialRandomDataProvider
  2. Transaction EvidenceEvidence Collector
  3. Row Integrity Hash · Financial EvidenceKey Generator · Evidence Pack
  4. Amount Validation Gate · EPK Integrity VerifierQuality Gate · Evidence Verifier
  5. Valid Transactions CSV · Rejected TransactionsCSV Publisher · CSV Publisher
nodes
tx-gen → Generators.Random
evidence-collector → Forensic.EvidenceCollector
integrity-hash → ETL.KeyGen
amount-gate → Sync.QualityGate
valid-output → CSV.Publisher
rejected-output → CSV.Publisher
evidence-pack → Forensic.EvidencePack
evidence-verifier → Forensic.EvidenceVerifier
every row hashedout-of-range amounts to a review tablepackage re-verified independently
  1. FinancialProduces 500 test transactions (seeded, repeatable).
  2. Transaction EvidenceHashes each row and batch into a Financial-level evidence manifest.
  3. Row Integrity HashAdds a keyed HMAC-SHA256 hash over amount, account and date.
  4. Financial EvidencePacks the manifest into a sealed evidence package.
  5. Amount Validation GateRange-checks amounts; failures go to a dead-letter table.
  6. EPK Integrity VerifierIndependently re-verifies the package.
  7. Valid Transactions CSVWrites accepted transactions.

A real workflow from our end-to-end test suite; the designer view is illustrated.

What you get. From the first pilot.

More scenario iterations per day on workstations.

Reserve and pricing figures are reproducible and traceable.

Sensitive claims data stays in the perimeter.

Why your tools fall short.

×

Legacy actuarial platforms are licence-heavy and slow to change.

×

Cloud grids add cost and third-party risk.

×

Spreadsheet-based models lack lineage.

What drives it
  • Supervisory scrutiny
  • Cost and speed of stochastic runs
  • Data-protection constraints
  • Climate/catastrophe scenario volume

Your pilot. Three steps.

1

Your data shape

Tell us what data you have, where it lives and what the result must be.

2

A scoped pilot

On your data and your hardware, with the success measure written down first.

3

A clear decision

You see the result against that measure — and keep every workflow and record.

Beta · design partners wanted

Bring us your hardest data problem. Let's solve it together.

A short pilot on your data and your hardware. We agree on what success looks like before we start.