Agent Banks moves money on behalf of autonomous software. That demands written controls, evidence that they run, and an owner accountable for both. This page is the public summary of the program governing our platform.
downloads a formatted, print-ready PDF of this program
section 1 — policy
Eight policies approved by leadership, reviewed at least annually, and binding on all staff and contractors.
The master policy. Defines scope (all systems that process cardholder, bank, or agent telemetry data), the security objectives of confidentiality, integrity and availability, and the authority of the Security Officer to enforce controls.
Least-privilege by default. Access is role-based, requested through a ticket, approved by a system owner, and granted for the minimum duration required. Production access is time-boxed and logged.
TLS 1.2+ in transit and AES-256 at rest for every datastore and backup. Card PANs are never stored by Agent Banks; they remain within the issuer processor's PCI-DSS environment and are referenced by token only.
Data is classified Public, Internal, Confidential, or Restricted. Raw card numbers are never held — customer cards are stored as network tokens only. Prompt traces and authorization logs are Restricted and retained for seven years to meet financial recordkeeping obligations.
Every change is peer-reviewed, passes automated dependency and secret scanning, and ships through an auditable CI pipeline. No direct writes to production. Infrastructure is defined as code and change-tracked.
Subprocessors handling regulated data must evidence SOC 2 Type II or equivalent before onboarding and are re-assessed annually. Current critical subprocessors: the bank-linking provider, the card issuer processor, and the cloud hosting provider.
A declared incident triggers a named incident commander, a severity rating, and a communication plan. Confirmed breaches affecting customer data are notified within 72 hours of confirmation, with a written post-incident report to affected customers.
Background checks where legally permitted, signed confidentiality agreements, and security training at onboarding plus annually. Phishing simulations are run each quarter with remedial training for failures.
section 2 — procedures
Each procedure names a trigger, a cadence, and the record it produces. A control without a record is not a control.
P-1
on event
Manager raises an access request naming the role and system. The system owner approves. Identity provider grants group membership. Offboarding triggers an automated revocation job; all sessions and API keys are killed within 24 hours and verified by the Security Officer.
P-2
per change
Branch, peer review, automated test and scan gates, then merge. Releases carry a change record with author, reviewer, and rollback plan. Emergency fixes are permitted but must be retro-documented within one business day.
P-3
continuous
Automated dependency scanning on every build. Remediation targets: critical within 7 days, high within 30, medium within 90. Exceptions require written risk acceptance by the Security Officer with an expiry date.
P-4
continuous
Authentication events, policy decisions, authorization outcomes, and administrative actions are logged immutably with a prompt trace identifier. Anomalous spend patterns and repeated declines raise alerts and can auto-pause an agent.
P-5
on event
Detect, declare, contain, eradicate, recover, review. Every Sev-1 and Sev-2 gets a blameless post-mortem within five business days with tracked corrective actions.
P-6
daily / annual test
Encrypted daily backups with point-in-time recovery. Recovery objectives: RPO 1 hour, RTO 4 hours. Restores are tested at least annually and the results documented.
P-7
quarterly
System owners recertify every user and service account against their role. Unjustified access is removed the same day and the review is retained as audit evidence.
P-8
annual
Threats to the platform are scored by likelihood and impact in a maintained risk register. Each risk gets an owner, a treatment decision, and a review date.
section 3 — operations
Security work is scheduled, not improvised. These cycles run whether or not an auditor is asking.
operating cadence
Weekly
Vulnerability triage, alert review, open incident stand-up
Monthly
Security metrics report to leadership, patch compliance check
Quarterly
Access recertification, phishing simulation, policy exception review
Annually
Risk assessment, policy refresh, DR restore test, penetration test, vendor re-assessment
accountability
Security Officer
Owns the program, approves exceptions, chairs incident reviews, and reports posture to leadership.
System owners
Accountable for access decisions, configuration, and recertification of the systems they run.
On-call engineering
First responders for availability and security alerts, following the incident runbook.
All personnel
Required to complete training, report suspected incidents immediately, and follow acceptable use.
audit evidence maintained
risk_register
owner, score, treatment, review date
access_reviews
quarterly recertification records
change_log
author, reviewer, deploy, rollback
incident_reports
timeline, impact, corrective actions
training_records
completion per employee per year
vendor_assessments
SOC 2 reports and review notes
section 4 — disclosure
We welcome coordinated disclosure and will not pursue action against good-faith research that respects customer data.
1. Report
Send details, reproduction steps, and impact to our security contact. Encrypt if the finding is sensitive.
2. Acknowledge
We confirm receipt within two business days and assign a severity and an owner.
3. Resolve
We share a remediation timeline, fix within the target for that severity, and credit you if you wish.
This page summarizes the program for public reference and is not a contract. Customers under NDA can request the full policy set, subprocessor list, penetration test summary, and current risk register. Program version 1.0 — reviewed annually.