Platform & Security

A platform that releases payments has to be a control platform.

Identity, isolation, traceability — described in enough detail to be reviewed.

This page exists for the people who have to sign off: CIO, security officer, internal audit, and the finance leader who is personally accountable for a payment release. It describes how control is built rather than asserting that the platform is secure — and it says plainly where a claim would need your own verification.

Request a technical review Platform architecture →
Identity and access

Access is a role, held by a person.

Finance systems fail on access long before they fail on architecture. Shared logins, inherited permissions and one all-powerful administrator are the usual findings — so none of them is possible by design.

Central identitySign-in runs through Microsoft Entra ID. The product stores no passwords.
Role-based accessRights are bound to roles, and roles to people. There are no shared accounts and no personal exceptions.
Entity scopeA role applies to defined entities, so visibility and action rights follow the organisational structure.
Segregation of dutiesPreparation, review and release are separate rights. Self-approval is blocked by the server-side rule, not discouraged by convention.
Least privilegeThe default is no access. Rights are granted deliberately rather than inherited by seniority.
Guarded interfaceEvery action is checked where it is executed, not only where it is displayed.
Isolation and separation

Your data is separated, and so are our environments.

Tenant isolation

Each tenant's data is separated at the data layer, not by a filter in the application. A query without a tenant context returns nothing.

  • Row-level security enforced on tenant-scoped data
  • Isolation checked in the data layer, not in the UI
  • No cross-tenant reporting path

Environment separation

Development, staging, verification and production are separate environments with separate data and separate access.

  • No development access to production data
  • Test data is not customer data
  • Access to each environment is a distinct right

Where the platform runs

FinanceOS runs on Microsoft Azure. The environments in operation are hosted in a European region, and the region applicable to your tenant is part of the contract rather than a marketing statement.

  • European hosting region
  • Region stated per tenant
  • Subprocessors named on request

Data in transit and at rest

Transport is encrypted, and stored data is encrypted at rest by the platform services in use. We describe the specifics in a technical review rather than summarising them into a badge.

  • Encrypted transport
  • Encryption at rest
  • Details available for your security questionnaire
Auditability and traceability

If it happened, it is recorded.

Auditability is not a reporting feature. It is the reason a finance operation can be run outside the ERP at all.

Append-only recordsEntries on financial objects are added, not overwritten. History cannot be quietly rewritten.
Who, what, when, whyEvery change, approval, rejection and override carries the person, the time and the basis.
Release evidenceA payment release keeps the rule that applied, the limit that was checked and the people involved.
Case historyExceptions and cases retain their documents and decisions, so a question next year does not require reconstruction.
Traceability to sourceA figure can be traced back to the system and record it came from — a projection is never anonymous.
Administrative actionsConfiguration and permission changes are recorded like business actions, because that is where the real risk sits.
Data quality

Unknown is not zero.

This is the design rule we are most often asked about, and the one that most clearly separates a finance platform from a dashboard.

Missing data is shown as missing. A cash position one source has not reached is an incomplete cash position and is labelled as such. Where a value cannot be derived honestly — a currency conversion without a reference rate, a ratio without an authoritative denominator — the platform produces no number at all instead of a plausible one. An empty state is a correct answer; a confident wrong number is not.

Fail closedWhen an input is missing, the platform withholds the result rather than substituting a default.
Source on the figureEvery value can name where it came from and as of when.
Honest empty statesA view with no data says so, and says what is missing.
Gaps are visibleAn incomplete projection is flagged where it is used, not only in a log.
Change and release governance

Changes reach your environment through one governed path.

A platform that moves money cannot be changed casually. The path from a change to your environment is itself controlled and recorded.

From change to your environment
  1. 1
    Change
  2. 2
    Review
  3. 3
    Automated verification
  4. 4
    Staging
  5. 5
    Acceptance
  6. 6
    Controlled release
  7. 7
    Rollback path

A release is only complete when the way back is proven as well. Rollback and restore are part of the release procedure, not an emergency improvisation.

Certifications and audits

What we claim, and what we don't.

We do not claim certifications we do not hold, and we do not use certification-adjacent wording to imply them. If your procurement or security process requires a specific certification, audit report or questionnaire, ask us directly: you will get a plain answer about what exists today, what we can evidence and what we cannot. That answer is more useful to your risk assessment than a badge on a website, and it is the same answer in every conversation.
What a security review covers

What a technical review with us actually covers.

A security review is a working session, not a slide deck. It is normally the second conversation, after the architecture is understood.

Identity and rolesHow your roles map to entities, approvals and limits.
IsolationHow tenant separation is enforced, and how you can verify it.
Audit expectationsWhat your auditors will ask for, and where it comes from.
Data protectionLegal bases, processing, retention and deletion for your case.
OperationsEnvironments, releases, rollback and how incidents are handled.
Your questionnaireWe answer yours rather than sending ours.
Next step

Send us the questions your security review has to answer.

Tell us which questions your CIO, security officer or auditor needs answered, and who needs to be in the room. We come back within one working day with what we can evidence today and what we would have to qualify.

  • What you get back. A clear answer per question — including the questions we cannot answer conclusively today.
  • Who answers. The people who built the controls, not a sales team with a security slide.
  • What can follow. A technical review with your reviewers, on your list of questions.
Receipt confirmed by email. Personal response within one working day.
The bottom line

Control by design, described in enough detail to check.

Identity, isolation, traceability and honest data — the architecture, not a badge.

Platform architecture Finance Operations Assessment