Securite & Conformite

Vue d'ensemble

En tant que fintech operant dans l'Espace Economique Europeen, YaniPay est soumise a un ensemble de reglementations strictes. Ces obligations sont partagees entre YaniPay (niveau 1) et les fournisseurs BaaS Swan/Treezor (niveau 2) qui detiennent les agrements bancaires.

PSD2 & SCA

La directive PSD2 (Payment Services Directive 2) impose l'authentification forte du client (Strong Customer Authentication - SCA) pour toute operation de paiement electronique. La SCA exige au moins deux facteurs parmi trois categories :

• Connaissance: quelque chose que l'utilisateur sait (mot de passe, PIN)
• Possession: quelque chose que l'utilisateur possede (telephone, carte physique)
• Inherence: quelque chose que l'utilisateur est (empreinte digitale, reconnaissance faciale)

Dans l'architecture YaniPay, la SCA est deleguee au fournisseur BaaS (Swan) qui gere le consentement via un flux de redirection. Le diagramme ci-dessous illustre le flux complet d'un virement SEPA avec SCA :

Apres la validation SCA, Swan emet un webhook Transaction.Bookedconfirmant l'execution du virement. YaniPay recoit ce webhook et met a jour le statut de la transaction dans la base de donnees locale.

Flux de consentement

L'endpoint de consentement permet a l'application mobile de recuperer l'URL de redirection SCA du fournisseur BaaS. Une fois le consentement accorde, l'utilisateur est redirige vers l'application.

1
// API endpoint: POST /api/v1/mobile/wallet/consent
2
export async function POST(request: Request) {
3
  const { consentId, action } = await request.json();
4
  const baas = getBaaSProvider();
5
6
  const consent = await baas.getConsent?.(consentId);
7
8
  if (!consent) {
9
    return Response.json({ error: 'Consent not found' }, { status: 404 });
10
  }
11
12
  // Redirect user to provider's SCA page
13
  return Response.json({
14
    redirectUrl: consent.consentUrl,
15
    purpose: consent.purpose,
16
    expiresAt: consent.expiresAt,
17
  });
18
}

Sur mobile, le flux de consentement utilise @swan-io/react-native-browserpour ouvrir une webview in-app securisee. L'utilisateur valide la SCA (biometrie ou SMS) puis est automatiquement redirige vers l'application.

PSD3 (2026-2028)

La directive PSD3, prevue entre 2026 et 2028, introduira des evolutions majeures dans le cadre reglementaire des services de paiement en Europe. Les principaux changements attendus sont :

• Open Finance: extension de l'Open Banking au-dela des comptes de paiement (assurances, investissements, pensions), elargissant les donnees accessibles via API
• Responsabilite renforcee: les prestataires de paiement auront une responsabilite accrue en cas de fraude, notamment pour les virements instantanes avec verification d'IBAN
• Verification IBAN: obligation de verifier la correspondance entre le nom du beneficiaire et l'IBAN avant l'execution d'un virement (Verification of Payee)
• Acces aux systemes de paiement : les etablissements de paiement pourront acceder directement aux systemes de compensation (TARGET, STEP2) sans passer par une banque intermediaire

ACPR & Agrement

L'ACPR (Autorite de Controle Prudentiel et de Resolution) est l'autorite francaise chargee de superviser les etablissements bancaires et les prestataires de services de paiement. Pour operer legalement des services de paiement en France, il est necessaire de disposer d'un agrement ACPR.

Swan et Treezor detiennent tous deux un agrement d'etablissement de paiement delivre par l'ACPR. YaniPay opere sous leur agrement en tant qu'agent de services de paiement. Ce modele d'agent (ou "umbrella") permet a YaniPay de proposer des services bancaires sans detenir son propre agrement, sous reserve de :

• Etre inscrit au registre des agents du fournisseur BaaS aupres de l'ACPR
• Respecter les procedures de conformite definies par le fournisseur (KYC, LCB-FT)
• Operer sous la supervision et la responsabilite du fournisseur BaaS
• Se soumettre aux audits reguliers du fournisseur et de l'ACPR

LCB-FT (AML)

La lutte contre le blanchiment de capitaux et le financement du terrorisme (LCB-FT) impose des obligations strictes en matiere de verification d'identite et de surveillance des transactions. Ces obligations sont reparties entre YaniPay et le fournisseur BaaS.

YaniPay implemente un systeme de scoring de risque base sur l'analyse des transactions. Les operations depassant certains seuils (montant, frequence, geographie) sont automatiquement signalees pour revue manuelle. Les declarations de soupcon sont transmises a Tracfin par le fournisseur BaaS.

RGPD

Le Reglement General sur la Protection des Donnees (RGPD) impose des obligations strictes sur le traitement des donnees personnelles des utilisateurs europeens. YaniPay applique les principes fondamentaux suivants :

1
// GDPR data export endpoint
2
export async function exportUserData(userId: string) {
3
  const user = await prisma.user.findUnique({
4
    where: { id: userId },
5
    include: {
6
      accounts: true,
7
      transactions: true,
8
      cards: { select: { id: true, last4: true, status: true } },
9
    },
10
  });
11
12
  // Sanitize sensitive fields before export
13
  return {
14
    profile: {
15
      email: user.email,
16
      name: user.name,
17
      createdAt: user.createdAt,
18
    },
19
    accounts: user.accounts.map(a => ({
20
      iban: a.iban,
21
      currency: a.currency,
22
      status: a.status,
23
    })),
24
    transactions: user.transactions.map(t => ({
25
      id: t.id,
26
      amount: t.amountCents / 100,
27
      currency: t.currency,
28
      date: t.bookedAt,
29
      label: t.label,
30
    })),
31
    exportedAt: new Date().toISOString(),
32
    format: 'GDPR-compliant-export-v1',
33
  };
34
}

MiCA

Le reglement MiCA (Markets in Crypto-Assets) est le cadre reglementaire europeen pour les crypto-actifs, en vigueur depuis 2024. Il concerne directement YaniPay en raison du YANICoin (YANI), le token natif de la plateforme.

Les principales implications pour YaniPay sont :

• Licence CASP(Crypto-Asset Service Provider) : YaniPay devra obtenir un enregistrement PSAN (Prestataire de Services sur Actifs Numeriques) aupres de l'AMF, ou un agrement CASP sous MiCA pour operer dans l'ensemble de l'UE
• Whitepaper reglementaire: obligation de publier un document d'information (crypto-asset white paper) detaillant les caracteristiques du YANICoin, les risques associes et les droits des detenteurs
• Reserve de fonds : si le YANICoin est classifie comme stablecoin (e-money token ou asset-referenced token), des reserves adequates devront etre maintenues
• Protection des consommateurs: obligation d'information claire sur les risques, droit de retractation de 14 jours pour les achats de crypto-actifs, et interdiction des pratiques commerciales trompeuses

1
// MiCA compliance checks for YANICoin operations
2
export function validateCryptoOperation(operation: CryptoOperation) {
3
  // Check if user has acknowledged risk disclosure
4
  if (!operation.user.hasAcceptedCryptoRiskDisclosure) {
5
    throw new ComplianceError(
6
      'MICA_RISK_DISCLOSURE_REQUIRED',
7
      'User must accept crypto-asset risk disclosure before trading'
8
    );
9
  }
10
11
  // Check 14-day cooling-off period for first-time buyers
12
  if (operation.type === 'BUY' && operation.user.isFirstCryptoPurchase) {
13
    return {
14
      ...operation,
15
      coolingOffPeriod: 14, // days
16
      cancellable: true,
17
      warningMessage: 'You have 14 days to cancel this purchase.',
18
    };
19
  }
20
21
  // Transaction limits per MiCA guidelines
22
  const dailyLimit = 15_000_00; // 15,000 EUR in cents
23
  if (operation.amountCents > dailyLimit) {
24
    throw new ComplianceError(
25
      'MICA_DAILY_LIMIT_EXCEEDED',
26
      'Transaction exceeds daily crypto-asset limit'
27
    );
28
  }
29
30
  return { ...operation, micaCompliant: true };
31
}

Securite des webhooks

Les webhooks sont le mecanisme principal par lequel le fournisseur BaaS notifie YaniPay des evenements asynchrones (transactions confirmees, changements de statut KYC, alertes de fraude). La securisation de ces webhooks est critique.

YaniPay implemente trois couches de securite pour les webhooks :

• Verification HMAC-SHA256 : chaque webhook est signe avec un secret partage. YaniPay recalcule la signature et la compare au header X-Swan-Signature
• Comparaison timing-safe : utilisation de crypto.timingSafeEqual() pour prevenir les attaques par timing sur la verification de signature
• Idempotence Redis : chaque eventId est stocke dans Redis avec un TTL de 24h pour eviter le traitement en double des webhooks rejoues

1
import crypto from 'crypto';
2
import { redis } from '@/lib/redis';
3
4
const WEBHOOK_SECRET = process.env.SWAN_WEBHOOK_SECRET!;
5
const IDEMPOTENCY_TTL = 86400; // 24 hours
6
7
export async function verifyWebhook(
8
  payload: string,
9
  signature: string,
10
  eventId: string
11
): Promise<{ valid: boolean; reason?: string }> {
12
  // 1. HMAC-SHA256 verification
13
  const expectedSignature = crypto
14
    .createHmac('sha256', WEBHOOK_SECRET)
15
    .update(payload)
16
    .digest('hex');
17
18
  const signatureBuffer = Buffer.from(signature, 'hex');
19
  const expectedBuffer = Buffer.from(expectedSignature, 'hex');
20
21
  if (signatureBuffer.length !== expectedBuffer.length) {
22
    return { valid: false, reason: 'Invalid signature length' };
23
  }
24
25
  // 2. Timing-safe comparison (prevents timing attacks)
26
  const isValid = crypto.timingSafeEqual(signatureBuffer, expectedBuffer);
27
  if (!isValid) {
28
    return { valid: false, reason: 'Signature mismatch' };
29
  }
30
31
  // 3. Redis idempotency check
32
  const alreadyProcessed = await redis.get(`webhook:${eventId}`);
33
  if (alreadyProcessed) {
34
    return { valid: false, reason: 'Event already processed' };
35
  }
36
37
  // Mark as processed with TTL
38
  await redis.set(`webhook:${eventId}`, '1', 'EX', IDEMPOTENCY_TTL);
39
40
  return { valid: true };
41
}

Variables d'environnement

Les variables d'environnement liees aux fournisseurs BaaS sont validees au demarrage de l'application via un schema Zod (lib/env-baas.ts). Toute variable manquante ou invalide provoque un echec immediat du demarrage.

1
import { z } from 'zod';
2
3
const baasEnvSchema = z.object({
4
  BAAS_PROVIDER: z.enum(['swan', 'treezor']).default('swan'),
5
  SWAN_CLIENT_ID: z.string().min(1, 'SWAN_CLIENT_ID is required'),
6
  SWAN_CLIENT_SECRET: z.string().min(1, 'SWAN_CLIENT_SECRET is required'),
7
  SWAN_WEBHOOK_SECRET: z.string().min(1, 'SWAN_WEBHOOK_SECRET is required'),
8
  NEXT_PUBLIC_APP_URL: z.string().url().default('http://localhost:3000'),
9
});
10
11
// Validate at startup — fail fast if missing
12
export const baasEnv = baasEnvSchema.parse(process.env);

Checklist production

Avant tout deploiement en production, verifiez que chaque element de cette checklist est correctement configure. Un seul element manquant peut compromettre la securite ou la conformite de la plateforme.

# Verifier que les variables critiques sont definies
echo "SWAN_CLIENT_SECRET: $([ -n "$SWAN_CLIENT_SECRET" ] && echo 'SET' || echo 'MISSING')"
echo "SWAN_WEBHOOK_SECRET: $([ -n "$SWAN_WEBHOOK_SECRET" ] && echo 'SET' || echo 'MISSING')"

# Verifier la connexion Redis
redis-cli ping

# Lancer les tests d'integration BaaS
pnpm test -- --grep "BaaS"

# Verifier les logs d'audit
tail -f logs/$(date +%Y-%m-%d).log | grep "baas"