Solutions / Banking and finance
Models that run under your controls in Switzerland and keep a record your auditors can read.
These scenarios are illustrations. None of them describes a client.
Compliance
What we would build
A screening assistant that groups hits by the person they actually describe, using the birth dates, places and employers mentioned in each article. Analysts review one card per real person with the matching evidence highlighted, and every dismissal is logged with its reason.
Python, spaCy, Mistral, PostgreSQL
Credit
What we would build
A document pipeline that reads balance sheets and tax statements, fills the rating template and marks each figure with the page it came from. The analyst starts from a checked draft and spends the time on the credit assessment itself.
Docling, Qwen3-VL, Python, FastAPI
Advisory
What we would build
An assistant that answers advisors' questions from the bank's own research and product documents, quoting the exact paragraph each answer comes from. It only searches documents the advisor is already allowed to open, and it runs on the bank's servers.
FAISS, vLLM, Llama, Keycloak
KYC operations
What we would build
An agent that gathers the client file from each system, checks expiry dates and missing items, and drafts the review summary with its sources. The analyst signs off on the complete file, and the agent has no permission to contact clients or approve anything.
LangGraph, Python, PostgreSQL, Avaloq API
AML
What we would build
A scoring model trained on past investigator decisions that ranks open alerts by risk and shows the transactions behind each score. The existing rules stay in place, the model sets the order in which people look, and its drift is checked every month.
XGBoost, SHAP, MLflow, Airflow
Client data stays in Switzerland, and a model that touches credit or compliance has to explain itself to someone in model validation who did not build it. We start from those two rules and work back to the use case, with a feasibility study on your own data before anything is promised.
Client-identifying data is protected by banking secrecy and many banks keep it out of foreign clouds, so models run on your own servers or with a Swiss provider.
FINMA Guidance 08/2024 expects a model that informs a credit or compliance decision to have an owner, tests and documentation.
Every suggestion a system makes is logged with its inputs and with the person who accepted or rejected it.
Most data sits in core platforms such as Avaloq, Finnova or Temenos and in document archives that will not change for this project, so integration reads from them as they are.
Yes. Open-weight models run on your own servers, or with a Swiss hosting provider if your outsourcing rules allow it. Nothing is sent to a foreign API, and we size the hardware during the feasibility study.
We work from FINMA Guidance 08/2024 on AI governance and document each model the way your model risk team expects: purpose, data, validation results, limits and monitoring. The documentation is a deliverable, written alongside the code.
No. In every scenario on this page a person approves the outcome. The system prepares the work and records why it suggested what it did.
Often more than for a large bank, because decisions are faster. Our page for SMEs, linked below, describes how a project runs at that size. A first study usually covers one process over a few weeks.
We start with a feasibility study on your own data, so you see results before anything is promised.