Le profil d'une banque sur STET 1.6.3

Le TPP doit-il s'enregistrer avant son premier appel, et par quel moyen ?

• Correspondance directeLe client_id est le numéro d'agrément lu dans le certificat eIDAS. La banque accepte la requête OAuth2 à la volée.
• Enregistrement manuelLa banque attribue un client_id lors d'un enregistrement préalable, en général sur son portail.
• Enregistrement automatiséLe TPP s'enregistre par l'API POST /register (RFC 7591), puis gère son enregistrement en GET, PUT et DELETE (RFC 7592).

La banque exige-t-elle un client_secret en plus du certificat ?

• mTLS seulLe TPP s'authentifie par son QWAC (RFC 8705). L'API d'enregistrement n'accepte que la méthode tls_client_auth.
• mTLS et secretCertains serveurs d'autorisation demandent quand même un client_secret. La spec le juge peu utile.

Un TPP peut-il avoir plusieurs client_id chez la même banque ?

• Un seulUn client_id par TPP.
• Un par contexte d'usageLa spec permet d'en obtenir plusieurs en rejouant l'enregistrement, en nombre raisonnable et pour un vrai besoin. Chaque agent du TPP compte comme un contexte distinct.

Quels contrôles la banque combine-t-elle pour calculer les droits du TPP ?

• Rôle du TPPLu dans le certificat eIDAS : PSP_AI, PSP_PI, PSP_IC.
• Accord TPP-banqueUn accord entre le TPP et la banque.
• Accord TPP-PSUPorté par le token OAuth2.
• Contexte du PSULes comptes et les droits du PSU chez la banque.

Les requêtes du TPP sont-elles signées en http-signature ou en JWS ?

• http-signatureDraft cavage, en-têtes Signature et Digest, RSA-SHA256. C'était le seul mécanisme jusqu'à la 1.6.2.
• JWSProfil JWS d'Open Banking Europe, en-tête X-JWS-Signature, algorithme choisi parmi ceux de la RFC 7518 et de l'ETSI TS 119 312. STET recommande fortement d'y passer.

La banque signe-t-elle ses réponses ?

• NonSeules les requêtes du TPP sont signées.
• OuiLes en-têtes Signature et Digest de réponse sont déclarés sur les réponses CBPII et PISP.

Comment le keyId désigne-t-il le certificat de signature ?

• kid de l'enregistrementLa valeur attribuée par le serveur d'autorisation lors de l'enregistrement OAuth2.
• URL du certificatUne URL qui sert le QSealC, dont le dernier segment se termine par _ suivi de l'empreinte SHA-256.

Quels en-têtes de contexte du PSU le TPP transmet-il ?

• Ceux dont il disposePSU-IP-Address, PSU-IP-Port, PSU-HTTP-Method, PSU-Date, PSU-User-Agent, PSU-Referer, les PSU-Accept*, PSU-GEO-Location, PSU-Device-ID.
• AucunQuand le PSU n'est pas connecté, par exemple pour un accès AISP en tâche de fond.

Comment la banque détecte-t-elle une requête rejouée ou un doublon ?

• Idempotency-KeyObligatoire sur POST /payment-requests, POST …/confirmation et POST /funds-confirmations, avec les règles d'unicité et d'expiration du draft IETF.
• paymentInformationIdUn indice pour éviter une double SCA ou une double exécution. La banque peut aussi utiliser ses propres mécanismes.

Par quel grant OAuth2 l'AISP obtient-il son token ?

• Authorization codeEn redirect, éventuellement enrichi de login_hint et ui_locales.
• OpenID ConnectEn redirect, avec les scopes openid et offline_access en plus.
• CIBAEn decoupled, en mode polling seulement.

Le serveur d'autorisation exige-t-il PKCE ?

• Non exigéLe code d'autorisation suffit.
• Exigécode_challenge et code_verifier deviennent obligatoires. Méthode plain par défaut, ou S256.

La banque implémente-t-elle OpenID Connect, et accepte-t-elle une requête signée ?

• OAuth2 seulPas d'IdToken.
• OpenID ConnectUn IdToken en plus des tokens. ui_locales devient obligatoire.
• Request Object signéSi le serveur l'accepte, les paramètres passent dans un JWT signé. Les paramètres en clair peuvent être envoyés à côté.

Le TPP peut-il transmettre un identifiant du PSU à la banque ?

• login_hintL'identifiant du PSU tel que la banque le connaît.
• login_hint_tokenUn jeton opaque émis par la banque après une première authentification, que le TPP renvoie dans une nouvelle demande.
• id_token_hintSi la banque a implémenté OpenID Connect.

Combien de temps vivent le code d'autorisation et l'access token ?

• Code d'autorisationDix minutes recommandées par la RFC 6749. Le serveur fixe sa propre valeur.
• Access tokenexpires_in est optionnel dans toutes les réponses token.

La banque émet-elle un refresh token, et le fait-elle tourner ?

• Pas de refresh tokenrefresh_token est optionnel dans les réponses authorization code, OpenID Connect et CIBA. Il n'existe jamais en client credentials ni pour la confirmation PISP.
• Sans rotationLe même refresh token sert jusqu'à sa révocation.
• Avec rotationLa réponse au refresh peut contenir un nouveau refresh token, qui remplace l'ancien.

Quand la banque révoque-t-elle le refresh token d'un AISP ?

• Délai réglementaireÀ l'échéance du délai légal entre deux SCA.
• Délai interneÀ l'échéance d'un délai propre à la banque, s'il y en a un.
• Sur demandeQuand le PSU révoque l'accès, ou quand le TPP révoque lui-même son refresh token (RFC 7009).

La banque expose-t-elle l'introspection de token ?

• NonLe TPP ne connaît que ce que la réponse token lui a donné.
• OuiRFC 7662. Le TPP introspecte ses propres tokens, et la réponse peut porter un login_hint_token.

À quel rythme le TPP interroge-t-il le token endpoint en CIBA ?

• interval fourniLa banque indique l'intervalle de polling dans sa réponse.
• interval absentLa spec ne donne pas de valeur par défaut. CIBA Core en donne une de cinq secondes.

Les URL de redirection sont-elles déclarées à l'avance ?

• DéclaréesLa banque compare l'URL reçue à celles déclarées à l'enregistrement, à l'identique.
• Non déclaréesredirect_uri est optionnel dans la requête /authorize.

Sur mobile, la redirection ouvre-t-elle l'appli de la banque ?

• NavigateurLe PSU s'authentifie sur le site mobile de la banque.
• App-to-appUniversal Link sur iOS, App Link sur Android, déclarés par l'appli de la banque pour son serveur OAuth2 et par l'appli du TPP pour son URL de retour.

Quelles approches d'authentification la banque propose-t-elle ?

• RedirectLe PSU est redirigé vers la banque, qui l'authentifie.
• DecoupledLa banque authentifie le PSU sur un autre canal, en général son appli.
• Les deuxLa banque choisit à chaque demande.

Quel identifiant du PSU la banque reconnaît-elle ?

• Identifiant nationalUn identifiant public de la personne.
• Identifiant clientL'identifiant que la banque attribue à son client.

Le PISP peut-il signaler qu'un paiement relève d'une exemption ?

• Sans indiceLa banque décide seule.
• scaHintnoScaExemption ou scaExemption, posé par le PISP dans supplementaryData.

L'AISP peut-il obtenir plus de 90 jours de transactions ?

• aispLe scope standard.
• aisp extended_transaction_historyValable avec le tout premier access token seulement. La banque le réduit à aisp au premier refresh.

La banque doit-elle connaître le détail du consentement donné à l'AISP ?

• A1, full-AISPLa banque ne connaît pas le détail du consentement. Elle répond à toute requête de l'AISP, sans pouvoir vérifier qu'elle respecte les choix du PSU.
• A2, mixteL'AISP transmet les choix du PSU par PUT /consents. GET /accounts renvoie tous les comptes éligibles, mais les liens HAL et les identifiants seulement pour les comptes consentis.

Le PSU a-t-il plusieurs espaces chez la banque ?

• Un espaceL'espace par défaut est celui de l'authentification qui a servi à obtenir le token.
• Plusieurs workspacesL'AISP les liste par le lien workspaces et cible l'un d'eux par le paramètre workspace.

Comment la banque expose-t-elle les cartes à débit différé ?

• Pas de compte carteLes opérations carte n'apparaissent qu'au débit sur le compte courant.
• Un compte CARD par carteUn compte de type CARD, rattaché au compte courant.
• Plusieurs par carteUn compte par date d'imputation.

Quels soldes la banque renvoie-t-elle ?

• Un soldeAu moins un, en principe le solde comptable pour un compte courant.
• PlusieursCLBD, XPCD, VALU, OTHR, PRCD, ITAV, chacun avec son libellé.
• Dans la liste des comptesLa banque peut inclure les soldes directement dans GET /accounts.

Que renvoie GET /transactions sans filtre, et selon quelle date ?

• Jeu par défautÀ documenter par la banque.
• Filtres de datesdateFrom inclus, dateTo exclu, dateType en transactionDate ou bookingDate.
• Filtres par référenceentryReferenceFrom, strictement supérieur, et entryReferenceto, inférieur ou égal.

La banque pagine-t-elle les listes ?

• Pas de paginationTout le résultat en une réponse.
• Liens HALfirst, last, next, prev, sans paramètre de taille de page.

Sur quel identifiant le TPP rapproche-t-il les transactions ?

• resourceIdL'identifiant de la ressource transaction.
• entryReferenceLa référence technique de l'écriture.
• AucunLa spec suggère alors de ne plus modifier remittanceInformation une fois posé.

Quels statuts de transaction la banque renvoie-t-elle ?

• BOOKLes opérations comptabilisées.
• PDNGLes opérations à comptabiliser qui affectent déjà le solde instantané.
• FUTR et INFOLes opérations à venir, et celles fournies pour information sans écriture.

Comment la banque code-t-elle le type d'opération ?

• ISO 20022Domaine, famille et sous-famille ISO.
• Codification nationaleDomaine FR, famille et code opération CFONB.
• Code propriétaireÀ documenter, avec son émetteur.

La banque fournit-elle le détail d'une transaction ?

• NonPas de lien details.
• Pour certaines transactionsUn lien details sur la transaction signale qu'un détail existe.

La banque expose-t-elle les titulaires d'un compte ?

• NonPas de lien owners.
• PersonnesUne liste identities, avec fullName obligatoire.
• SociétéUn bloc company.

La banque expose-t-elle l'identité du PSU connecté ?

• NonPas de lien endUserIdentity.
• OuiGET /end-user-identity, avec fullName obligatoire, et prénom, nom et civilité optionnels.

La banque expose-t-elle le découvert autorisé ?

• NonPas de lien overdrafts.
• OuiGET /accounts/{id}/overdrafts, qui ne renvoie que allowedAmount.

La banque expose-t-elle la liste des bénéficiaires de confiance ?

• NonRéponse 501, et le drapeau isTrusted ne doit jamais apparaître.
• OuiGET /trusted-beneficiaries, et isTrusted sur chaque bénéficiaire.

Combien d'accès par jour la banque accepte-t-elle sans le PSU ?

• Quatre en 24 heuresLe minimum réglementaire.
• DavantageSi l'AISP et la banque en conviennent, avec le consentement du PSU.

Quel token le CBPII utilise-t-il pour vérifier la couverture ?

• Avec le PSUAuthorization code, OpenID Connect ou CIBA, après une SCA.
• Client credentialsQuand le PSU a enrôlé le CBPII au préalable auprès de sa banque.

La vérification porte-t-elle sur un compte ou sur une carte ?

• CompteIdentifié par son IBAN.
• CarteIdentifiée par other, avec CPAN, MPAN ou TPAN.

Comment le PSU confirme-t-il un paiement ?

• Enforced redirectLe PSU est redirigé vers la banque. Après la SCA, le PISP obtient un access token par authorization code et s'en sert pour sa propre confirmation.
• DecoupledLa banque authentifie le PSU sur un autre canal, appelle directement l'URL de retour du PISP, puis le PISP confirme avec son token client credentials.

La banque demande-t-elle une SCA pour annuler un paiement ?

• NonappliedAuthenticationApproach vaut NONE et l'annulation est effective tout de suite.
• Simple redirectLe PSU est redirigé vers la banque pour confirmer l'annulation.
• DecoupledLa banque fait confirmer l'annulation sur un autre canal.

Quels types de demandes de paiement la banque accepte-t-elle ?

• Virement uniqueUne instruction, un bénéficiaire.
• Plusieurs bénéficiairesÀ la même date d'exécution.
• Plusieurs datesPour le même bénéficiaire.
• Ordre permanentUne instruction, un bénéficiaire, une fréquence.

Quels instruments de paiement la banque accepte-t-elle ?

• SCTVirement SEPA.
• SCT InstlocalInstrument à INST.
• Domestique hors euroAvec codes de déclaration réglementaire.
• InternationalAvec date et lieu de naissance du créancier.

Que fait la banque quand un virement instantané ne peut pas partir en instantané ?

• RejetacceptInstantPaymentDowngrade à false, la valeur par défaut.
• RétrogradationSi le PISP l'accepte, la banque passe en SCT classique et retire INST de localInstrument.

Le PISP fournit-il le compte débiteur, et la banque peut-elle le changer ?

• Fourni par le PISPdebtorAccount renseigné.
• Choisi chez la banquedebtorAccount absent. La spec ne décrit pas ce choix, qui se fait en principe pendant l'authentification.
• ModifiableacceptDebtorAccountChange, à true par défaut, autorise la banque à le changer.

Qui supporte les frais, et la banque peut-elle changer ce choix ?

• chargeBearerSLEV, SHAR, CRED ou DEBT selon l'instrument.
• acceptChargeHandlingChangeÀ true par défaut, autorise la banque à modifier la répartition.

Quand le virement part-il, et que fait la banque si la date n'est pas possible ?

• Dès que possiblerequestedExecutionDate absent.
• Date demandéeLa date de débit souhaitée.
• Date décaléePour un paiement qui n'est pas un ordre permanent, la banque peut passer à la prochaine date possible.

Quelles fréquences et règles d'exécution la banque accepte-t-elle pour un ordre permanent ?

• FréquencesDAIL, WEEK, TOWK, MNTH, TOMN, QUTR, SEMI, YEAR, ou un sous-ensemble.
• Règle d'exécutionFWNG ou PREC, si la banque en ligne la supporte.
• FinSans endDate, l'ordre est sans fin.

Combien d'instructions une demande peut-elle contenir, et sont-elles comptabilisées en lot ?

• PlafondChaque banque fixe le maximum de numberOfTransactions.
• Batch bookingLa banque a sa valeur par défaut, et le PISP peut la fixer.

Quelles informations de remise la banque accepte-t-elle ?

• Non structuréeUne occurrence au plus.
• StructuréeUne occurrence au plus.
• Les deuxElles peuvent coexister.

Le PISP fournit-il une URL de retour distincte pour l'échec ?

• Une seule URLsuccessfulReportUrl, utilisée aussi en cas d'échec.
• Deux URLsuccessfulReportUrl et unsuccessfulReportUrl.

Combien de temps et sous quelle forme le statut d'un paiement reste-t-il consultable ?

• 30 joursLe minimum fixé par la spec.
• DavantageSelon les règles de la banque.
• Endpoint des transactionsGET /payment-requests/{id}/transactions, optionnel, signalé par un lien transactions.

Que dit la banque au PISP sur un virement immédiat non instantané ?

• Comptabilisébooking à true.
• Fonds disponibles ou nonSi le système ne sait pas comptabiliser tout de suite, booking à false et fundsAvailability renseigné.

La banque explique-t-elle pourquoi elle rejette un paiement ?

• Motif précisUn code parmi AC01, AC04, AC06, AG01, AM02, AM04, AM18, FF01, FRAD, NOAS, entre autres.
• Sans motifMS03, « No reason specified by the ASPSP ».

Comment la banque publie-t-elle son implémentation de la spec ?

• Fichier STET adaptéhost obligatoirement personnalisé, basePath et URL d'autorisation et de token personnalisables.
• Écarts marquésVersion de référence dans x-stet-psd2-api-reference-version, définitions dérivées marquées x-original-definition.

Comment la banque répond-elle à un appel vers une fonction qu'elle n'offre pas ?

• 400Le point d'entrée n'est pas implémenté du tout.
• 501Il est implémenté mais ne peut pas répondre dans ce contexte.
• 405 et 406Méthode non supportée, ou format de réponse non proposé.

Quels types de référence de compte la banque accepte-t-elle ?

• IBANLe cas courant.
• Autres schémasBANK, BBAN, COID, SREN, SRET, NIDN, et aussi OAUT, CPAN, MPAN, TPAN, TBAN.

Quelles règles de transport et de format s'appliquent au-delà du minimum ?

• TLS 1.2 minimumHSTS ou PFS possibles en plus.
• HTTP 1.1 minimumUne version plus récente est permise.
• DatesLe créateur choisit son fuseau, UTC recommandé, et sa précision.

La banque prévoit-elle un accès de secours si l'interface dédiée tombe ?

• Mécanisme de secoursLes TPP utilisent l'interface client de la banque, en s'identifiant, jusqu'au rétablissement (art. 33(4) des RTS).
• ExemptionAccordée par l'autorité, après consultation de l'EBA (art. 33(6)).

Que couvre l'environnement de test de la banque ?

• Connexion et certificatsÉtablir le mTLS, échanger les certificats, recevoir les messages d'erreur.
• Parcours fonctionnelsAIS, PIS et confirmation de fonds, avec des données de PSU fictives.
• AuthentificationToutes les procédures d'authentification offertes aux clients.