Control the execution. Keep the evidence.

Access with defined boundaries

The platform implements authenticated access, tenant checks, and a permission catalogue for protected operations. Token validation checks signatures, issuer, audience, and expiry. Sensitive operator workflows can require multi-factor authentication.

Deployment configuration, identity integration, and operational access are reviewed for each environment.

Financial controls are part of the core

• Idempotency: repeat attempts do not create a second logical instruction.
• Unknown outcomes: a missing response triggers investigation, rather than an assumption that money did not move.
• Evidence history: records and decisions remain traceable to their source.
• Bounded agents: investigation and recommendations operate within explicit permissions.

What agents can and cannot do

Agents help people understand payments. They read, correlate, investigate, explain, and draft. They can request a deterministic action, such as a status lookup or a file re-fetch, through the same controlled commands a person would use.

Agents never, on their own:

• move money or change a payment, posting, ledger entry, or evidence item;
• resolve an unknown outcome by assumption or override idempotency;
• close an exception, accept a settlement, or write off a difference;
• change routing policy, reconciliation rules, or posting rules;
• contact a provider or a customer without a person sending the message.

Every tool call an agent makes is recorded as an event with the agent as the actor.

Connect with the least access needed

Reconciliation can start with read-only transaction sources. Partner callbacks are verified before they are interpreted, and raw evidence is retained with references to its source.

Credentials, partner configurations, data flows, and retention requirements are agreed during integration. Never send live credentials or production customer records through a general contact enquiry.

Evidence you can audit

• Raw files, callbacks, and responses are stored with a hash and their provenance before they are interpreted.
• Events are appended and never edited. A correction is a new, explained record.
• Every financial decision keeps the evidence, the rule version, and the person or rule that made it.

Security & standards

Our security discussions cover the following frameworks where they are relevant to a deployment:

• PCI DSS (PCI Security Standards Council)
• SOC 2 (AICPA)
• ISO/IEC 27001 (ISO)
• PSD2 (EUR-Lex, Directive (EU) 2015/2366)
• ISO 20022 (ISO 20022 Registration Authority)
• GDPR (EUR-Lex, Regulation (EU) 2016/679)

References to these standards are not a statement that a certification, audit, licence, or regulatory approval has been obtained. Request the current assurance materials and applicable scope during your review.

Report a security concern

Send a description of the issue, the affected page or service, reproducible steps, and any non-sensitive supporting details. Avoid exposing customer data, disrupting services, or testing systems you are not authorised to access.

Security contact: sanjay@flominzo.com. Our security.txt file follows RFC 9116.