Compliance
The regulatory surface an account operating system has to serve, and the boundary between what the platform does and what remains the institution’s.
Last updated 23 July 2026 · Trust Center
Read this first. The platform is a means of discharging your obligations. It is not a transfer of them, and it is not a compliance programme. Your institution remains responsible for its programme, its filings and its supervisory relationship.
1. The boundary
| The platform | The institution |
|---|---|
| Enforces the rule you configure, at the moment of the transaction | Decides what the rule is |
| Produces the evidence that the rule was applied | Reviews, escalates and files |
| Blocks or flags a transaction against configured criteria | Determines suitability, permissibility and acceptance of risk |
| Retains records for the period you configure | Sets the retention period the law requires of it |
2. Onboarding and screening
Identity and entity verification, beneficial-ownership capture, and sanctions and watchlist screening are integration points rather than opinions. The platform holds the verified attributes, the evidence of verification, the expiry, and the authorization consequence — an expired attribute changes what a caller may do, at the next decision.
Screening providers are deployment-specific and appear in your subprocessor exhibit.
3. Account-type rules
Account types differ in what they permit, and the differences are the compliance surface. Contribution and distribution limits, age and event triggers, prohibited-transaction and disqualified-person checks, unrelated business income, plan-level testing, titling requirements for alternative assets, and valuation cadence are properties of the account type rather than custom code per institution.
This is the part of Stage 1 in the de novo path that propagates furthest: your permitted-activity list becomes a set of enabled account types and workflows.
4. Information reporting
Reporting is treated as a feature of the account core rather than a separate product, because the data that produces a return is the same data that produced the transaction. Reporting obligations vary by account type and by jurisdiction; your order form records which the deployment produces.
5. Recordkeeping
Records are retained for the period configured for your deployment, and deletion is performed against that configuration rather than on request in an ad hoc way. Retention interacts with the DPA — where a retention commitment cannot be performed in full we name the system that limits it rather than making the commitment anyway.
6. AI governance
Where automation or a model contributes to a decision, three things are required and are treated as non-negotiable: the decision is attributable, the inputs relied on are recorded, and a human can be placed in the path by configuration. A model does not receive an authorization exemption — a model acting on a record is a caller, and is evaluated as one, with its own purpose and delegation.
Tenant data is not used to train models that serve other customers.
7. Regulatory change
Rules change. Because account-type behaviour is configuration rather than bespoke code, a change is a configuration change with a version and an effective date, and the evidence trail records which version was in force when a given transaction was decided. That is the property that makes a look-back answerable.
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.
8. Financial-crime monitoring
The Bank Secrecy Act puts the AML program — and the filings — on the financial institution. A8 Core™’s job is to make that program operable: real-time transaction events instead of batch files, complete ledger history behind every alert, and authorization evidence that answers “who was permitted to do what” before a case is even opened. Know-your-transactions (KYT) monitoring itself runs through governed specialist integrations today, with a native module planned — the financial-crime monitoring page states the status plainly.
Three specifics worth naming. SARs and CTRs remain the institution’s filings; the platform makes them producible — currency thresholds visible in real time, the record behind a suspicious-activity narrative already assembled. Sanctions screening against OFAC and equivalent lists runs at onboarding and on an ongoing basis through the same integration surface as identity verification. Beneficial ownership: entity accounts carry their ownership structure as data, so identifying ultimate beneficial owners — the substance of KYB and of beneficial-ownership reporting — is a query, not a project.