TREN
Book demo
Sign in
PlatformTreasury and cash managementFinancingRisk and complianceCheques and notesReconciliation and accountingPaymentsSecurity and data
SolutionsOpen banking and bank integrationERP and accounting integrationsMulti-entity groupsGuarantees and letters of credit
CompanyAbout usBlogBecome a partnerContact
Pricing
Platform

Security and data

In a treasury at a multi-entity holding company, who can see what and who can approve what is defined in the product’s first layer.

Data isolation

Organisations’ data never mixes

Every record is tagged with its organisation, and access control is enforced in the database layer. Not the application layer.

Even a badly written query cannot return another organisation’s data; this guarantee does not depend on the application code being correct.

This rule is continuously measured by automated checks; every table and every policy is verified to actually separate organisations.

Authorisation

Who sees what, who does what

Permissions are defined on two axes: which legal entities you can access, and which actions you are allowed.

The holding company CFO sees the whole group; a subsidiary manager sees only their own entity. The same person can have read access in one module and write access in another.

Role definitionsOwner, treasury manager, analyst, auditor.
Access per legal entityAt group, entity or account level.
Permissions per moduleRead, write and approve are granted separately.
Signing authority is separateApproval authority in the system and signing authority at the bank are different things, kept apart.
Approval and segregation of duties

No single person can complete a transaction start to finish

The person who prepares a request cannot approve it. This rule is enforced at the database level and cannot be bypassed from the application layer.

Multiple signatures are required by amount band, and the number needed is frozen at request time; it cannot be lowered later by changing the threshold. Changing the band table itself is also subject to approval.

Segregation of dutiesThe preparer cannot approve; the rule stands as a database constraint.
Frozen signature countThe number of signatures needed is frozen at request time.
A request that cannot be approved never sits silentlyIf there are fewer authorised signatories than the threshold requires, it is reported as a configuration error; the request never sits forgotten in a queue.
Audit trail

Every decision can be explained after the fact

Records are never deleted, only their status changes. A cancelled payment batch, a closed loan, a returned bank guarantee — all of it stays on record.

The reason is simple: if a calculation used that record, how the result came about must be explainable afterwards.

Change logWho changed what, and when.
Approval historyWho approved which request, at what band, at what rate.
Data source and freshness

When the data was read is always visible

Every block of data carries its last update time. When a connection drops, this is never hidden. Affected totals are flagged, and which accounts were left out is written down.

Stale data is never presented as if it were current.

Personal data

Data protection compliance

Retention periods and access logs are defined. The personal data processing inventory is prepared together with your organisation’s processes during onboarding.

For audit-trail reasons, records are never deleted; requests concerning personal data are handled through a separate process.

Hosting

Where it runs

The entire system is deployed on-premises on your own servers, and your data stays with you.

Let’s do your security assessment together

In the meeting we walk through the permission matrix and audit trail using your own organisation structure.

Book demo Home