Frema Labs

Par secteur

Par technologie

Par taille d'entreprise

Partez de votre secteur, de la technologie que vous envisagez ou de la taille de votre entreprise.Toutes les solutions
Discutons

Solutions / Banque et finance

IA pour les banques suisses soumises à la FINMA

Des modèles exploités en Suisse sous votre contrôle, qui gardent une trace lisible par vos auditeurs.

Décrire votre cas

Ce que nous pourrions construire

Ces scénarios sont des illustrations. Aucun ne décrit un client.

Conformité

Chaque matin, les analystes relisent les mêmes alertes de presse négative, et la plupart concernent une personne au nom semblable.

Ce que nous construirions

Un assistant de filtrage qui regroupe les alertes selon la personne réellement décrite, à partir des dates de naissance, des lieux et des employeurs cités dans chaque article. Les analystes examinent une fiche par personne réelle, avec les éléments concordants surlignés, et chaque classement sans suite est consigné avec son motif.

Python, spaCy, Mistral, PostgreSQL

Crédit

Chaque dossier de crédit PME arrive sous forme d'une pile de PDF, et un analyste passe la première journée à saisir des chiffres dans l'outil de notation.

Ce que nous construirions

Un pipeline documentaire qui lit les bilans et les déclarations d'impôt, remplit la grille de notation et indique pour chaque chiffre la page d'où il vient. L'analyste part d'un brouillon vérifié et consacre son temps à l'analyse de crédit proprement dite.

Docling, Qwen3-VL, Python, FastAPI

Conseil

Avant un rendez-vous client, les conseillers fouillent les house views, les fiches produits et les règles d'adéquation, répartis sur quatre intranets.

Ce que nous construirions

Un assistant qui répond aux questions des conseillers à partir des analyses de la banque et de ses documents sur les produits, en citant le paragraphe exact d'où vient chaque réponse. Il ne cherche que dans les documents que le conseiller a déjà le droit d'ouvrir, et il tourne sur les serveurs de la banque.

FAISS, vLLM, Llama, Keycloak

Opérations KYC

Les revues KYC périodiques piétinent parce que les documents sont dispersés dans cinq systèmes et que certains ont expiré sans que personne le remarque.

Ce que nous construirions

Un agent qui reconstitue le dossier client à partir de chaque système, contrôle les dates d'expiration et les pièces manquantes, et rédige la synthèse de revue avec ses sources. L'analyste valide le dossier complet, et l'agent n'a aucun droit de contacter les clients ni d'approuver quoi que ce soit.

LangGraph, Python, PostgreSQL, Avaloq API

Lutte anti-blanchiment

Les règles de surveillance des transactions génèrent des centaines d'alertes par semaine, et les enquêteurs les classent presque toutes en faux positifs.

Ce que nous construirions

Un modèle de scoring, entraîné sur les décisions passées des enquêteurs, qui classe les alertes ouvertes par niveau de risque et montre les transactions qui expliquent chaque score. Les règles existantes restent en place, le modèle fixe l'ordre dans lequel les alertes sont examinées, et sa dérive est contrôlée chaque mois.

XGBoost, SHAP, MLflow, Airflow

Les contraintes de départ

Les données clients restent en Suisse, et un modèle qui touche au crédit ou à la conformité doit pouvoir s'expliquer devant l'équipe de validation des modèles, qui ne l'a pas construit. Nous partons de ces deux règles pour remonter jusqu'au cas d'usage, avec une étude de faisabilité sur vos propres données avant toute promesse.

  1. Secret bancaire

    Les données d'identification des clients sont couvertes par le secret bancaire, et beaucoup de banques les tiennent hors des clouds étrangers, si bien que les modèles tournent sur vos propres serveurs ou chez un prestataire suisse.

  2. FINMA et risque de modèle

    Dans sa communication sur la surveillance 08/2024, la FINMA attend qu'un modèle qui éclaire une décision de crédit ou de conformité ait un responsable, des tests et une documentation.

  3. Piste d'audit

    Chaque suggestion d'un système est enregistrée avec ses données d'entrée et le nom de la personne qui l'a acceptée ou rejetée.

  4. Systèmes centraux en place

    L'essentiel des données se trouve dans des plateformes bancaires centrales comme Avaloq, Finnova ou Temenos et dans des archives documentaires qui ne changeront pas pour ce projet. L'intégration les lit donc telles qu'elles sont.

Les questions qu'on nous pose

Oui. Les modèles à poids ouverts tournent sur vos propres serveurs, ou chez un hébergeur suisse si vos règles d'externalisation le permettent. Rien n'est envoyé à une API étrangère, et nous dimensionnons le matériel pendant l'étude de faisabilité.

Nous partons de la communication FINMA sur la surveillance 08/2024, consacrée à la gouvernance de l'IA, et documentons chaque modèle comme l'attend votre équipe chargée du risque de modèle : finalité, données, résultats de validation, limites et surveillance. La documentation fait partie des livrables et s'écrit en même temps que le code.

Non. Dans chaque scénario de cette page, une personne approuve le résultat. Le système prépare le travail et consigne la raison de chacune de ses suggestions.

Souvent plus que pour une grande banque, parce que les décisions se prennent plus vite. Notre page consacrée aux PME (lien ci-dessous) décrit le déroulement d'un projet à cette échelle. Une première étude porte en général sur un seul processus et dure quelques semaines.

Solutions associées

Technologies

Secteurs

Taille d'entreprise

Quel dossier votre équipe relit-elle chaque matin ?

Nous commençons par une étude de faisabilité sur vos propres données : vous voyez des résultats avant toute promesse.

Décrire votre casNotre méthode