Logiciels bancaires

// Le problème

Les demandes de prêt d’entreprise arrivent par courriel, les notes de crédit sont rédigées à partir de zéro, et l’emprunteur appelle la succursale pour savoir où en est son dossier.

// Ce que nous bâtirions

Un portail web pour les directeurs de comptes et les analystes de crédit, avec une application iOS et Android pour les propriétaires d’entreprise, qui porte le dossier de la demande à l’octroi puis au suivi des clauses, branché sur le système bancaire central.

// Ce qu’il comprend

// Technologies

• Next.js
• React Native
• PostgreSQL
• Intégration au système bancaire central
• API du bureau de crédit
• AWS Canada

// Le problème

La surveillance des opérations produit une file d’alertes que les analystes ne peuvent pas vider, et les vraies activités douteuses attendent derrière des milliers de faux positifs.

// Ce que nous bâtirions

Un modèle sur mesure affiné à partir des alertes fermées et des notes d’analystes de la banque, qui roule sur des serveurs GPU dans le centre de données de la banque pour que les opérations des clients n’en sortent jamais, et qui classe chaque alerte en expliquant pourquoi à l’analyste qui décide.

// Ce qu’il comprend

// Technologies

• PyTorch
• Python
• PostgreSQL
• Next.js
• Serveurs GPU Lenovo sur place

// Le problème

Plusieurs coopératives de crédit vérifient séparément les mêmes membres entreprises et leurs propriétaires effectifs, et chacune garde sa copie de documents qui se périment.

// Ce que nous bâtirions

Un registre privé à permissions où chaque caisse participante exploite un nœud et inscrit qu’une vérification a été faite, par qui et quand, pendant que les documents restent chez l’institution qui les a recueillis. Un regroupement doté d’un exploitant de confiance pourrait plutôt utiliser une base de données partagée.

// Ce qu’il comprend

// Technologies

• Hyperledger Besu (privé, à permissions)
• Next.js
• PostgreSQL
• AWS Canada

// Le problème

Le personnel de première ligne fouille un lecteur partagé de procédures, de bulletins et de grilles de taux pour répondre à un membre, et trouve souvent une version périmée.

// Ce que nous bâtirions

Un assistant qui répond à partir des procédures en vigueur seulement et cite le document et la section, sur un modèle open source servi dans le propre compte AWS de la banque au Canada pour que les politiques internes y restent.

// Ce qu’il comprend

// Technologies

• Llama ou Mistral (open source)
• vLLM
• PostgreSQL avec pgvector
• Next.js
• AWS Canada

// Le problème

Les rapports au conseil et à la direction d’une caisse sont assemblés chaque mois à partir d’extraits du système bancaire central, du système de prêts et de tableurs, et deux rapports montrent rarement le même chiffre.

// Ce que nous bâtirions

Un entrepôt de données au Canada qui charge chaque nuit les données bancaires, de prêts et de cartes dans un seul modèle aux définitions convenues, pour que tableaux de bord et rapports au conseil partent des mêmes chiffres, avec un accès par rôle et un journal des consultations.

// Ce qu’il comprend

// Technologies

• PostgreSQL
• dbt
• Apache Superset
• Python
• AWS Canada

// Le problème

Les agents de crédit d’une caisse utilisent une application de bureau maison pour les demandes et les approbations, qu’un seul contractuel comprend, et chaque changement est lent et risqué.

// Ce que nous bâtirions

Une modernisation par étapes : nous documentons ce que fait l’ancienne application, écrivons des tests qui fixent son comportement, puis la reconstruisons écran par écran en application Web, en faisant tourner les deux côte à côte jusqu’à ce que la nouvelle donne les mêmes réponses.

// Ce qu’il comprend

// Technologies

• Next.js
• PostgreSQL
• TypeScript
• Playwright
• DigitalOcean