Case projections for organisations, in batches, across borders

An organisation sends the figures it holds for the people it plans for — a pot, a monthly amount, a currency, a country — and gets a projection for each of them under each plan it wants to compare. Thousands at a time, from its own systems, over an API.

This is not available yet, and the page says so on purpose. The arithmetic is finished and running — the table below is real — but there is no account to open, nothing to buy, and the API is deliberately not exposed. What is missing is listed at the foot of this page. If it is the shape of thing you need, write to contact@valnivo.eu and say what your systems look like.

Try it on your own numbers

Below is the same calculation the API performs, running in this page. Nothing is sent anywhere: there is no request, no account and no server involved, which is also why you can put real figures in it. Each case is discounted by its own country’s inflation, which is the difference between a projection and a projection that assumes everybody lives in one place.

What the request looks like

One call carries up to 200 cases, each with up to 10 plans. A plan inherits the case’s figures and overrides whatever it names, so comparing “as things are” with “€300 more a month” is one extra line rather than a second case.

POST /v1/cases/projections
Authorization: Bearer <your key>

{
  "cases": [
    {
      "ref": "A-1042",              // your reference. never a name
      "country": "LU",
      "currency": "EUR",
      "starting": 1000000,          // minor units: €10,000.00
      "monthly": 50000,
      "plans": [
        { "ref": "as things are",  "years": 20, "returnRate": 0.05 },
        { "ref": "€300 more",      "years": 20, "returnRate": 0.05, "monthly": 80000 }
      ]
    }
  ]
}

Every figure is an integer in minor units in both directions, so nothing arrives as a float nobody can reconcile. One bad case comes back in rejected with its reference rather than failing the batch — a firm sending thousands cannot lose the answer over one typo.

Cases carry no identity, and the API refuses it

What a case may hold

Accepted

Figures, a currency, an ISO country code, and your own reference. That is enough to project, and it is all we want.

What it may not

Refused by name

A name, an e-mail, a phone number, an address, a date of birth, an account number or a national identifier. The request comes back naming the field it will not take.

Why refuse rather than ask

A promise in a document is a promise. Refusing the field at the boundary is a measure: you cannot send us identity by accident, and there is none here to lose.

How the responsibilities divide

You are the controller; we are the processor. The figures are yours, collected from your own clients under your own basis. A data processing agreement is a contract to sign, not a page to accept, and it comes before any real data moves.
The people behind the figures are your clients, not our users. They never meet us and have no account with us. Telling them their data is processed is your duty under art. 14; what we do is keep our side small enough that it stays easy.
The API stores nothing today. It is arithmetic on the request. There is no database, so there is nothing to retain, breach or delete — and the day that changes, it will be written down here before it is built.

What it will never do

These are not features waiting to be prioritised. They are the boundary that keeps this a calculation rather than a regulated activity, and it is the same boundary the consumer app lives inside.

Never say what a person can afford, borrow or should do. Modelling a plan the firm chose is arithmetic; assessing a person is not, and a creditworthiness judgement is a lender’s own regulated duty.
Never name, rank or compare a fund, account, provider or policy. That is investment advice or intermediation, whoever asks for it.
Never connect to a bank. Fetching accounts or balances is an account information service under PSD2, needing authorisation or a licensed aggregator.
Never take a referral fee. Commission for sending somebody to a broker or insurer makes the tool an intermediary regardless of wording.

Every figure the API returns carries the same sentence with it: illustrations built on the assumptions in the request, not a forecast, not advice, and not a statement of what anyone can afford or should do.

What has to be true before it opens

A company. A data processing agreement needs a signatory and an invoice needs an entity. This is the first blocker and it is not a technical one.
Somewhere to run it. Hosting a service costs money the project does not spend yet; today the API runs on a laptop, by design.
Keys that mean something — issued per organisation, revocable, and not an environment variable.
Professional terms and the processing agreement, published and reviewed, plus the privacy notice extended to a category of person we never meet.
Rate limits, an audit trail and an exit plan, because procurement will ask, and a firm that must keep records for five years needs to know where they live.