Security

Last updated 23 July 2026 · Trust Center

1. The governing principle

Authentication establishes who is calling. It does not establish whether that caller may reach this record, for this purpose, under the delegation in force right now. Most incidents in financial infrastructure are not authentication failures — they are authenticated callers reaching data they should not have reached, which no perimeter control catches.

So authorization is evaluated per data element and the decision is recorded. That is the difference between asserting a control to an examiner and evidencing it. See Authorization for the mechanics.

2. Identity and access

• Multi-factor authentication required for privileged access.
• Least privilege by default; entitlements are granted narrowly and reviewed on a schedule and on personnel change.
• Administrative actions are themselves authorized per data element and logged with the acting identity, purpose and delegation.
• Credentials and keys are held in managed secret storage, never in source control, client-side code or support tickets.

3. Data protection

Data is encrypted in transit and at rest. Tenant data is logically isolated, and a caller in one tenant cannot resolve a record identifier in another — isolation is enforced at the authorization layer rather than being a property of the query alone.

Aggregated, de-identified operational telemetry is used to run, secure and improve the platform. Tenant data is not used to train models that serve other customers.

4. Segregation of duties

An examiner will ask who can initiate, who can approve, and whether those can be the same person. The platform expresses that as configuration: approval thresholds, dual control on defined actions, and delegation that can be revoked downward without involving anyone else. Because those are enforced rather than procedural, the evidence is a by-product rather than a reconstruction.

5. Logging and evidence

Access and change decisions produce a tamper-evident record intended to be sufficient for your own audit and examination obligations — the identity, the record, the purpose, the delegation relied on, the decision and the time. See Examination support for what that looks like in an exam.

6. Hosting and isolation

All environments run on Microsoft Azure. Region is a configurable property of a deployment — see Data residency. Non-production environments must not hold production personal data unless the order form expressly permits it.

7. People

Personnel with access to customer data are subject to written confidentiality obligations that survive their engagement, background screening appropriate to the role, and security training. Access is removed as part of offboarding rather than after it.

8. What we do not yet have

Stated plainly, because a reviewer will find it anyway and would rather find it here.

• No published third-party audit report yet. Where a current report or completed questionnaire exists we offer it before asking you to run your own audit; where it does not, we say so.
• No chartered trust entity. Institutional Trust Company is seeking a South Dakota non-depository trust charter and is not yet chartered.
• Early-stage evaluation records — NDAs and evaluation agreements signed before provisioning — are captured in a system whose retention we will name on request. Production execution moves to a dedicated document-execution provider.

Financial Infrastructure, Inc. is a technology provider and is not a bank, trust company, broker-dealer or investment adviser. Nothing on this page is legal, regulatory, tax or investment advice. Institutional Trust Company is a proposed trust entity seeking a South Dakota non-depository trust charter; it is not yet chartered and is not accepting accounts.

Questions about this document? Contact security@a8core.com or write to Financial Infrastructure, Inc., PO Box 1410, Menlo Park, California 94026-1410.