Security & LLM governance

Data sovereignty by architecture, not by contract

The EyesClear Platform runs inside the bank’s own environment, and the AI runs on that same private infrastructure. No customer data and no model inference leaves for an external cloud or a third-party vendor. The LLM is sandboxed inside the platform, given only in-house tools, and fed only the data the bank has explicitly granted. EyesClear Investigations is a separate, optional service that searches the public records from outside the perimeter; § 04 sets out exactly what it sends.

01 Security & data architecture

Five properties of the deployment

On-premise and data residency: EyesClear deploys inside your own environment — on-premise or private cloud — and the AI runs on that same infrastructure. No customer data and no model inference goes to an external cloud or a third-party vendor. Data sovereignty is guaranteed by architecture, not by contract.
Deployment topology: Containerised microservices — data collection, message processing, alerting, case management, reporting and portal — on PostgreSQL with horizontal scaling, an in-memory cache for real-time evaluation, and a private LLM gateway. One engine serves real-time and back-dated processing as two modes.
Data and confidentiality management: Connection strings, integration credentials and API keys are held as encrypted, centrally managed parameters — never embedded in code or configuration. Connectivity is validated before a source goes live.
Access control and segregation: Role-based access profiles, departments and divisions set what each user can see and do, down to menu visibility and data partitioning. Analysts reach only the data their mandate permits, and entitlements are managed centrally.
Connectivity: Universal connectors take SWIFT and ISO 20022, real-time queues (MQ and Kafka), and database and file sources covering CRM, transactions, risk and KYC — mapped into the single data fabric.

02 LLM security

Containment by design

LLM technology is a genuine game changer, and it must be fully understood before it touches production. The value is too large to ignore. As with every process a bank operates, good governance is what removes the risk.

Sandboxed by design

The LLM runs inside EyesClear only. It has no access to bank systems, databases or applications. It sees the case data the Platform hands it, and nothing else. Containment is enforced by architecture, not by a prompt or a policy.

In-house tools, deliberately

Everything the agents can do is defined by tools written in-house. Each one is a known, audited capability with defined inputs and outputs. An LLM without tools is a parrot; an LLM with uncontrolled tools is a risk. Ours gets exactly the tools the workflow needs, and no more.

Rules-based collection, not crawling

Your analysts and technology teams configure every source, field and refresh. Some tools in the market crawl internal data instead. The results look impressive, but in our view that pattern is not secure enough for a bank. Nothing is read that was not explicitly granted.

AI value without data-export risk.

LLM security, enforced by architecture

03 Defensibility

What an examiner can be shown

Explainability: The AI never decides on its own. Every output traces back to the source data and is reviewed, edited and approved by an analyst before it is acted on. There is no black-box score to defend.
Auditability: All evidence, case history and decisions are held centrally with full audit trails and instant retrieval for any period. Activity logging records who opened which screen and what they did — examination and internal audit without folder-shuffling.
Model and change governance: Maker-checker (four-eyes) governs every material configuration change — scenarios, thresholds, typologies, case templates, report types, user permissions — with a full record of who requested it and who approved it.

How the Platform works →How we compare →FAQ →

04 EyesClear Investigations

The one thing that runs outside, and what it sends

EyesClear Investigations is a separate, hosted service that searches the public records. It is not part of the Platform deployment, it is provisioned separately, and the Platform does not require it.

What it does not touch: It has no connection to the Platform's data fabric and no access to customer records, transactions, alerts or cases. Nothing in the Platform is exposed by running it.
What does leave: The name being screened, and the search terms derived from it, are sent to the public sources and the language models the service uses. That is the whole of it — no customer file, no transaction, no alert. Treat a screening as a public-record enquiry about a named subject, and scope it the way your policy scopes one.
Why it is not inside the perimeter: The evidence it gathers is on the open web, so the search has to happen there. Putting the service inside the bank would not keep the enquiry inside the bank; it would only move where the request originated.

What Investigations does →

Two services, one boundary, and it is written down.

Bring your security team

The architecture questions are the ones we like being asked. A demo can start with the deployment diagram rather than the dashboard.

Start screening Request a demo