○ Comment coder le SLA dans la réponse

	○ Demander à un 2e CNP de router
	
	○ Dans l’API — il faut empaqueter comment y parvenir
	
	○ En tant que CMP dans Mowali, si je renvoie une réponse de devis, le schéma a des implications
	
	○ Suivre tout le parcours du payeur au bénéficiaire
	
	○ Limiter la participation du CNP — il doit être le dernier saut
	
		§ Comment définir les exigences d’un CNP ?

- Format des messages

	○ Syntaxe HTTP
	
	○ Parti du schéma Mojaloop
	
		§ Évoluer vers le fait que le CNP gère la conversion
	
	○ Version SWIFT
	
	○ Sécurité — TLS
	
	○ En-tête / contenu chiffrés en JWS

- Système de détail

	○ Hors réseau — envoi vers un hub

- Modèle de données

	○ Structure : façons d’ajouter de nouvelles informations, routes différentes, etc.
	
	○ Confidentialité : visibilité et sécurité — accessible seulement aux personnes autorisées
	
	○ Contenu du modèle de données

- Le transfert passe par le switch (mouvement d’argent)

	○ Dans Mowali — les montants sont exprimés mais le taux est important car il impacte les règlements

	§ Flux de données — on ajoute le taux quand on renvoie le devis
	
	§ Ajouté dans la liste d’extensions — doit-il faire partie du standard ?

	§ Montant envoyé et reçu (devises différentes)

- Élément de données
	
	○ Frais pour chaque participant
	
	○ Le DFSP payeur les additionne
	
	○ Élément de frais pour la transaction

- Proposition

	○ Service de recherche de compte

		§ Liste des FSP locaux
	
	○ Switch — doit maintenir l’état et les requêtes de recherche

		§ Doit ressembler à un transfert domestique pour l’émetteur
		
		§ Collecter les informations et les renvoyer
	
	○ CNP — faire des hypothèses pour satisfaire les exigences
	
		§ Faut-il voir la route
		
		§ Collecter des informations différentes en aval
		
		§ Les FSP émetteurs doivent savoir qui est le bénéficiaire
		
	○ Le CNP doit agréger les informations et les regrouper en une seule requête ; signatures séparées
		
		§ Condition et exécution font partie d’une structure PKI
		
		§ S’il y a plus d’un CNP — il faut s’assurer que le DFSP bénéficiaire est certain du DFSP payeur — connexions
		
		§ Le CNP doit tout savoir, reporting réglementaire
		 
	○ Faut-il dupliquer la structure dans un transfert inter-réseaux ?
		
		§ Empêcher un partenaire indésirable de se joindre
		
		§ Faire confiance au CNP pour respecter ses SLA
	
	○ Mojaloop vers un autre schéma — nous n’avons pas le contrôle
	
		§ Exiger qu’ils confirment la réception
		
		§ Comment le savoir
		
		§ Comment savoir que la personne en bout de chaîne a reçu l’argent
	
	○ Autorité de signature externe pour confirmer la réception des fonds
	
		§ Si votre schéma veut participer au transfrontalier, tous les participants doivent être signés
		
		§ Clé publique — pour rejoindre un réseau Mojaloop il faut émettre des clés publiques
		
		§ Autorité centrale de certification
		
		§ Besoin d’une structure PKI en place
	
	○ Comment intégrer des acteurs non Mojaloop au schéma ?
	
		§ Comment intégrer Mojaloop et un schéma Mojaloop pour des paiements PVT complets — groupe de travail avec Michael, Adrian, Sybrin, autres au besoin
		
		§ Identifier les participants — FSP, DFSP — tous signés
		
		§ Parties — utilisateurs finaux (Bob / Alice)
		
		§ Transaction unique (avec plusieurs transferts)
		
		§ Personne n’engage ses fonds tant que tout le monde n’est pas satisfait
		
		§ Comment étendre Mojaloop et un schéma non Mojaloop
	
	○ Certification
	
		§ Hachage et PKI
	
		§ Réseau or et argent

		§ Nouveau partenaire — en ligne sur le réseau
		
		§ Le schéma décide des exigences sur le réseau
		
		§ Certificat auto-signé
	
	○ Liquidité
	
		§ Le FXP fait la gestion de position
		
		§ Quelles exigences imposer à un FXP
		
		§ L’argent mobile a moins de flexibilité
		
		§ Règles qui s’appliquent entre schémas
	
	○ Le FXP doit gérer les règlements, ce qui expire quand, etc.
	
		§ Le FXP doit gérer le manque de validité des devis
		
		§ Permettre au FXP de rejeter les requêtes

	○ Comment gérer les demandes pour motifs réglementaires
	
		§ Il existe un dictionnaire
		
			□ Exigence de partager le KYC ?
		
			□ On peut demander beaucoup de choses — à la charge du participant
			
			□ Besoin d’accord sur le schéma de base

- Données du switch

	○ Numéros de compte
	
	○ Liste noire, liste blanche (supervision et blocage)
	
	○ Garder la simplicité
	
	○ Hub
	
	○ Service annexe pour ceux qui peuvent faire cela
	
		§ Capture de données mobiles
		
		§ Sidecar
		
		§ Processus numérique
		
		§ Services à valeur ajoutée pour le hub (service géré)

- Switch — doit maintenir l’état et les requêtes de recherche

- Le CNP peut être un DFSP ordinaire

	○ Tous les DFSP supportent tous les cas d’usage
	
	○ Participants complets (peuvent fournir seulement un service CNP ou FXP)

- Définition et exigences du FXP

	○ FXP — exiger taux / frais dans le service de devis — besoin d’un taux industrie standard
	
		§ Les CNP peuvent étendre et définir des règles de schéma supplémentaires
	
	○ Le FXP gère les erreurs d’arrondi
	
	○ Garantir un taux donné
	
	○ Gérer le règlement entre schémas
	
	○ Taux de change
	
	○ Devrait permettre aux acteurs qui ne font que du FX
	
	○ Cas limites en cas d’échec
	
		§ Détails dans les messages d’erreur pour localiser les erreurs
	
	○ Le FXP doit renvoyer les bonnes informations
	
		§ Comment les messages circulent
		
		§ Cas limites — partager ce qui est fait à ce jour
		
		§ Jo a une API fonctionnelle — identifiée
		
		§ Modifier le devis (intercepter le devis) —
		
		§ Liste d’extensions KYC — étendu le devis pour cela
		
		§ Les taux sont dans la liste étendue (sont la liste)
		
		§ Où le FXP s’applique-t-il ?
		
		§ Que faire des frais en aval
		
			□ (le DFSP bénéficiaire prend la place de l’agrégation)

- Comment gérer la résolution d’identifiants

	○ 2 types d’identifiants
	
		§ Globaux (passés au CNP) — pour obtenir une réponse
		
		§ Locaux — on attend que l’utilisateur fournisse
	
	○ Dans Mojaloop nous utilisons les identifiants comme proxy
	
	○ Les numéros marchands peuvent être spécifiques à un schéma
	
	○ Plusieurs identifiants pour un seul compte
	
	○ Comment identifier de façon unique le compte ?
	
	○ S’appuyer sur le CNP (restreindre chaque identifiant dans ce schéma)
	
	○ Quelles structures mettre en place
	
	○ Identification passeport — espaces réservés
	
	○ Cartographier comptes Pathfinder / mobile vers identifiants uniques DFSP
	
		§ Service — compte principal est X
		
		§ Chaque pays a un service qu’il fournit
		
		§ Chaque CNP comprend le schéma d’adresse
		
		§ Identifiant global — savoir quelles voies utiliser
	
	○ Envoie un get parties au switch
	
		§ L’ALS ne les a jamais connus
		
		§ 2 voies
		
			□ Voie globale (pathfinder et conversion vers BIC)
- CNP

	○ N’héberge rien

	○ Route via le CNP — solliciter d’autres acteurs
	
	○ Construire des routes alternatives

- Pas de registre global

	○ Bénéficiaire ultime
	
	○ Communication établie
	
	○ Défi : deux DFSP pourront-ils partager une communication directe — ce sera difficile ?

- Le switch a des schémas

	○ Un opérateur de hub suivant les règles du système peut autoriser les noms de FSP selon ces règles
	
	○ La technologie ou l’Admin API elle-même ne restreint pas les noms (sauf longueur, type, caractères, etc.)
	
	○ BGP : Border Gateway Protocol

- Interroger chaque CNP puis optimiser, matrice de route globale — objectif : ne pas interroger le CNP directement

- Tout service financier peut se connecter à Mowali

- Règles techniques et du schéma

- Réglementaire

- Comment assigner les choses ? — personne ne connaît les étapes

- API Mojaloop — comprendre cela.

- 2 instances Mojaloop — TIPs et Mowali

	○ WOCCU, Asie, US — demande d’instance
	
	○ On repousse encore les limites

- À quoi ressemble une intégration

	○ Besoin de bac à sable, simulateurs
	
	○ Approche standard

- Faire circuler les flux en temps utile

- Besoin de grands livres en temps réel ; que se passe-t-il s’ils sont hors ligne ?

- Exception pour hors réseau (les banques profitent du float)

- Le switch détermine s’il doit contacter un FXP

- Dans quelle devise le compte bénéficiaire peut recevoir

- Recherches multiples

- Modèle de données — ensemble de comptes, avec une devise par DFSP

- Mike, Patricia — Thume

- Michael R, Rob R, Sam — Modusbox

- Kim, Lewis — Crosslake

- Rolland, Greg, Phillip — Sybrin

- Vanburn — Terrapay

- Megan, Simeon — Virtual