Ertas for Finance

The Challenge

Financial institutions operate in one of the most data-rich and regulation-heavy environments on the planet. From risk modeling and fraud detection to regulatory reporting and customer communications, the potential applications for AI are enormous, but so are the stakes. A hallucinated compliance report or an inaccurate risk score can trigger regulatory action, financial loss, and reputational damage. Generic language models lack the domain knowledge to parse SEC filings, interpret Basel III capital requirements, or distinguish between legitimate transaction patterns and subtle fraud indicators.

At the same time, financial data is among the most sensitive categories of information that exists. Customer account details, trading strategies, proprietary risk models, and internal audit findings are all subject to overlapping regulatory frameworks: SOX for internal controls, PCI-DSS for payment data, SEC and FINRA rules for trading and advisory activities, and GDPR or CCPA for customer personal data. Sending any of this information to a third-party AI provider's API introduces data-residency, auditability, and vendor-risk concerns that most compliance teams will reject outright.

The Solution

Ertas lets financial institutions build domain-specific models they own and run on their own infrastructure. In Ertas Studio, quantitative analysts and data science teams fine-tune open models with LoRA on financial datasets: earnings call transcripts, internal research notes, anonymized transaction records and regulatory filings. Runs can be repeated, several can run in parallel, and the team compares them before choosing one. The resulting models learn the financial terminology, accounting standards and market conventions in your own examples. Training runs on Ertas's cloud GPUs, so the training set is uploaded to Ertas: anonymize or minimise it first, and keep raw account numbers and customer PII out of it.

Once a model passes your own evaluation, you export it from Hub as GGUF or safetensors and serve it inside your VPC or on-premise data center with vLLM, llama.cpp or Ollama. Inference requests and outputs stay on those servers, the model has no dependency on Ertas at runtime, and your existing access controls, logging and model risk management processes apply to it like any other internal system. Teams already sending a task to a frontier model through API calls can also ask about the adaptive model endpoint, which can run Ertas-managed, in your own cloud, or on-premise. For a larger build, Ertas's enterprise team starts with a free use-case audit and a three-to-four-week proof of concept, and the institution owns the trained model.

Key Features

Example Workflow

A regional bank's risk analytics team wants to improve its fraud review workflow. The team exports 200,000 anonymized transaction records, labeled with confirmed fraud cases, removes raw account numbers and customer PII, and uploads the result to Ertas Studio as a JSONL dataset. Fraud analysts review a sample in Data Craft, writing and approving the explanation for each flagged case. In Studio, the team runs LoRA fine-tuning on Mistral 7B and Llama 3.1 8B in parallel, targeting transaction classification and anomaly explanation, and compares both runs against a held-out set of cases its analysts have already decided. The team exports the stronger model from Hub as safetensors and serves it with vLLM inside the bank's on-premise data center, reachable only from the fraud monitoring pipeline. The model scores transactions and flags suspicious patterns with explanations that analysts review, and the team measures false positives against its current rules before widening the rollout. Live customer data stays inside the bank's network, and the bank's own monitoring systems log the model's inputs and outputs.