Logiciels financiers

// Le problème

Un prêteur reçoit ses demandes par formulaire web et par courriel, alors la vérification d’identité, les données bancaires et les documents se courent à la main et bien des demandeurs ne terminent jamais.

// Ce que nous bâtirions

Une application iOS et Android, avec un portail web assorti, qui vérifie l’identité, lie le compte bancaire, recueille les documents et montre au demandeur où en est son dossier, plus un back-office pour l’équipe de crédit.

// Ce qu’il comprend

// Technologies

• Next.js
• React Native
• PostgreSQL
• Flinks ou Plaid pour les données bancaires
• API de vérification d’identité
• AWS Canada

// Le problème

Le volume de soutien grimpe à chaque campagne de marketing, et la plupart des billets posent des questions auxquelles le centre d’aide public répond déjà.

// Ce que nous bâtirions

Un agent de soutien sur un modèle de pointe qui répond à partir du centre d’aide publié et confie à une personne tout ce qui touche un compte précis, choisi parce que la matière est publique et que c’est la voie la plus rapide vers le lancement.

// Ce qu’il comprend

// Technologies

• API d’un modèle de pointe
• PostgreSQL avec pgvector
• Next.js
• Intégration Zendesk ou Intercom
• DigitalOcean

// Le problème

Les analystes retapent les revenus et les dépenses à partir des relevés bancaires et des talons de paie, ce qui est lent et glisse des fautes de frappe dans les décisions de crédit.

// Ce que nous bâtirions

Un agent sur un modèle open source, servi dans votre propre compte AWS au Canada pour que les documents financiers n’aillent jamais chez un tiers, qui lit chaque document, en extrait les montants et montre à l’analyste chaque valeur à côté de la ligne d’où elle vient.

// Ce qu’il comprend

// Technologies

• Qwen ou Llama (open source)
• vLLM
• Python
• PostgreSQL
• Next.js
• AWS Canada

// Le problème

Une entreprise de paiement et ses institutions partenaires tiennent chacune leur propre registre des virements et des règlements, et la fin de mois devient un débat sur qui a le bon.

// Ce que nous bâtirions

Un registre privé à permissions où chaque partie exploite un nœud, et où chaque virement et chaque règlement est écrit une fois et lu par tous, avec une console web pour l’équipe des opérations. Si une seule partie peut tenir le registre en toute confiance, une base de données partagée coûte moins cher et nous vous le dirons.

// Ce qu’il comprend

// Technologies

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

// Le problème

Cabinets-conseils et applications partenaires veulent les données de comptes et de portefeuilles, et les reçoivent aujourd’hui en fichiers de nuit ou en extrayant des écrans.

// Ce que nous bâtirions

Une API partenaire avec consentement OAuth 2.0, pour que chaque client choisisse ce qu’une application peut voir, et du TLS mutuel entre vos serveurs et ceux de chaque cabinet. Elle est bâtie pour une disponibilité visée de 99,95 %, et ses versions se retirent selon un calendrier que vous publiez.

// Ce qu’il comprend

// Technologies

• OpenAPI 3.1
• OAuth 2.0 et OpenID Connect
• TypeScript sur Node.js
• PostgreSQL
• AWS au Canada

// Le problème

La plateforme d’un prêteur tourne sur des serveurs configurés à la main il y a des années, les déploiements se font tard le soir en croisant les doigts, et les questionnaires de sécurité de ses partenaires sont chaque année plus difficiles.

// Ce que nous bâtirions

Le transfert vers un nuage géré dans des régions canadiennes, configuré en code, avec stockage chiffré, sauvegardes testées, déploiements par étapes, journaux d’accès lisibles par vos vérificateurs et un forfait mensuel où nous l’exploitons, le mettons à jour et en rendons compte.

// Ce qu’il comprend

// Technologies

• Terraform
• AWS Canada
• PostgreSQL
• Grafana
• GitHub Actions