El perfil de un banco en STET 1.6.3

¿Debe el TPP registrarse antes de su primera llamada, y por qué medio?

• Correspondencia directaEl client_id es el número de autorización que figura en el certificado eIDAS. El banco acepta la petición OAuth2 al vuelo.
• Registro manualEl banco asigna un client_id en un registro previo, en general en su portal.
• Registro automatizadoEl TPP se registra mediante la API POST /register (RFC 7591) y después gestiona su registro con GET, PUT y DELETE (RFC 7592).

¿Exige el banco un client_secret además del certificado?

• Solo mTLSEl TPP se autentica con su QWAC (RFC 8705). La API de registro solo acepta el método tls_client_auth.
• mTLS y secretoAlgunos servidores de autorización piden de todos modos un client_secret. La especificación lo considera poco útil.

¿Puede un TPP tener varios client_id en el mismo banco?

• Uno soloUn client_id por TPP.
• Uno por contexto de usoLa especificación permite obtener varios repitiendo el registro, en un número razonable y por una necesidad real. Cada agente del TPP cuenta como un contexto distinto.

¿Qué controles combina el banco para calcular los derechos del TPP?

• Rol del TPPSe lee en el certificado eIDAS: PSP_AI, PSP_PI, PSP_IC.
• Acuerdo TPP-bancoUn acuerdo entre el TPP y el banco.
• Acuerdo TPP-PSULo refleja el token OAuth2.
• Contexto del PSULas cuentas y los derechos del PSU en el banco.

¿Las peticiones del TPP se firman con http-signature o con JWS?

• http-signatureDraft cavage, headers Signature y Digest, RSA-SHA256. Fue el único mecanismo hasta la 1.6.2.
• JWSPerfil JWS de Open Banking Europe, header X-JWS-Signature, algoritmo elegido entre los de la RFC 7518 y la ETSI TS 119 312. STET recomienda encarecidamente migrar a él.

¿Firma el banco sus respuestas?

• NoSolo se firman las peticiones del TPP.
• SíLos headers de respuesta Signature y Digest están declarados en las respuestas CBPII y PISP.

¿Cómo designa el keyId el certificado de firma?

• kid del registroEl valor que asigna el servidor de autorización durante el registro OAuth2.
• URL del certificadoUna URL que sirve el QSealC, cuyo último segmento termina en _ seguido de la huella SHA-256.

¿Qué headers de contexto del PSU transmite el TPP?

• Los que tenga disponiblesPSU-IP-Address, PSU-IP-Port, PSU-HTTP-Method, PSU-Date, PSU-User-Agent, PSU-Referer, los PSU-Accept*, PSU-GEO-Location, PSU-Device-ID.
• NingunoCuando el PSU no está conectado, por ejemplo en un acceso AISP en segundo plano.

¿Cómo detecta el banco una petición repetida o un duplicado?

• Idempotency-KeyObligatorio en POST /payment-requests, POST …/confirmation y POST /funds-confirmations, con las reglas de unicidad y expiración del draft del IETF.
• paymentInformationIdUn indicio para evitar una doble SCA o una doble ejecución. El banco también puede usar sus propios mecanismos.

¿Con qué grant OAuth2 obtiene el AISP su token?

• Authorization codeEn redirect, opcionalmente con login_hint y ui_locales.
• OpenID ConnectEn redirect, añadiendo los scopes openid y offline_access.
• CIBAEn decoupled, solo en modo polling.

¿Exige PKCE el servidor de autorización?

• No exigidoBasta con el código de autorización.
• Exigidocode_challenge y code_verifier pasan a ser obligatorios. Método plain por defecto, o S256.

¿Implementa el banco OpenID Connect, y acepta una petición firmada?

• Solo OAuth2Sin IdToken.
• OpenID ConnectUn IdToken además de los tokens. ui_locales pasa a ser obligatorio.
• Request Object firmadoSi el servidor lo acepta, los parámetros van en un JWT firmado. Los parámetros en claro pueden enviarse junto a él.

¿Puede el TPP transmitir al banco un identificador del PSU?

• login_hintEl identificador del PSU tal como lo conoce el banco.
• login_hint_tokenUn token opaco emitido por el banco tras una primera autenticación, que el TPP reenvía en una nueva solicitud.
• id_token_hintSi el banco ha implementado OpenID Connect.

¿Cuánto duran el código de autorización y el access token?

• Código de autorizaciónDiez minutos, según recomienda la RFC 6749. El servidor fija su propio valor.
• Access tokenexpires_in es opcional en todas las respuestas de token.

¿Emite el banco un refresh token, y lo rota?

• Sin refresh tokenrefresh_token es opcional en las respuestas authorization code, OpenID Connect y CIBA. Nunca existe en client credentials ni para la confirmación PISP.
• Sin rotaciónEl mismo refresh token sirve hasta que se revoca.
• Con rotaciónLa respuesta al refresh puede contener un nuevo refresh token, que sustituye al anterior.

¿Cuándo revoca el banco el refresh token de un AISP?

• Plazo regulatorioAl vencer el plazo legal entre dos SCA.
• Plazo internoAl vencer un plazo propio del banco, si lo hay.
• A peticiónCuando el PSU revoca el acceso, o cuando el propio TPP revoca su refresh token (RFC 7009).

¿Expone el banco la introspección de token?

• NoEl TPP solo conoce lo que le dio la respuesta de token.
• SíRFC 7662. El TPP hace introspección de sus propios tokens, y la respuesta puede incluir un login_hint_token.

¿Con qué frecuencia consulta el TPP el token endpoint en CIBA?

• interval presenteEl banco indica el intervalo de polling en su respuesta.
• interval ausenteLa especificación no da ningún valor por defecto. CIBA Core fija uno de cinco segundos.

¿Se declaran de antemano las URL de redirección?

• DeclaradasEl banco compara la URL recibida con las declaradas en el registro, y exige una coincidencia exacta.
• No declaradasredirect_uri es opcional en la petición /authorize.

¿Abre la redirección la app del banco cuando el PSU está en el móvil?

• NavegadorEl PSU se autentica en la web móvil del banco.
• App-to-appUniversal Link en iOS, App Link en Android, declarados por la app del banco para su servidor OAuth2 y por la app del TPP para su URL de retorno.

¿Qué enfoques de autenticación ofrece el banco?

• RedirectEl PSU es redirigido al banco, que lo autentica.
• DecoupledEl banco autentica al PSU en otro canal, por lo general su app.
• AmbosEl banco elige en cada solicitud.

¿Qué identificador del PSU reconoce el banco?

• Identificador nacionalUn identificador público de la persona.
• Identificador de clienteEl identificador que el banco asigna a su cliente.

¿Puede el PISP indicar que un pago se acoge a una exención?

• Sin indicaciónEl banco decide solo.
• scaHintnoScaExemption o scaExemption, que el PISP pone en supplementaryData.

¿Puede el AISP obtener más de 90 días de transacciones?

• aispEl scope estándar.
• aisp extended_transaction_historyVálido solo con el primer access token. El banco lo reduce a aisp en el primer refresh.

¿Debe el banco conocer el detalle del consentimiento dado al AISP?

• A1, full-AISPEl banco no conoce el detalle del consentimiento. Responde a cualquier petición del AISP, sin poder verificar que respeta las elecciones del PSU.
• A2, mixtoEl AISP transmite las elecciones del PSU con PUT /consents. GET /accounts devuelve todas las cuentas elegibles, pero los enlaces HAL y los identificadores solo para las cuentas consentidas.

¿Tiene el PSU varios espacios en el banco?

• Un espacioEl espacio por defecto es el de la autenticación con la que se obtuvo el token.
• Varios workspacesEl AISP los lista con el enlace workspaces y apunta a uno de ellos con el parámetro workspace.

¿Cómo expone el banco las tarjetas de débito diferido?

• Sin cuenta de tarjetaLas operaciones con tarjeta solo aparecen cuando se cargan en la cuenta corriente.
• Una cuenta CARD por tarjetaUna cuenta de tipo CARD, vinculada a la cuenta corriente.
• Varias por tarjetaUna cuenta por fecha de cargo.

¿Qué saldos devuelve el banco?

• Un saldoAl menos uno, en principio el saldo contable para una cuenta corriente.
• VariosCLBD, XPCD, VALU, OTHR, PRCD, ITAV, cada uno con su etiqueta.
• En la lista de cuentasEl banco puede incluir los saldos directamente en GET /accounts.

¿Qué devuelve GET /transactions sin filtro, y según qué fecha?

• Conjunto por defectoDebe documentarlo el banco.
• Filtros de fechadateFrom incluido, dateTo excluido, dateType con transactionDate o bookingDate.
• Filtros por referenciaentryReferenceFrom, estrictamente mayor, y entryReferenceto, menor o igual.

¿Pagina el banco las listas?

• Sin paginaciónTodo el resultado en una sola respuesta.
• Enlaces HALfirst, last, next, prev, sin parámetro de tamaño de página.

¿Con qué identificador concilia el TPP las transacciones?

• resourceIdEl identificador del recurso transacción.
• entryReferenceLa referencia técnica del asiento.
• NingunoEn ese caso, la especificación sugiere no volver a modificar remittanceInformation una vez asignado.

¿Qué estados de transacción devuelve el banco?

• BOOKLas operaciones contabilizadas.
• PDNGLas operaciones pendientes de contabilizar que ya afectan al saldo en tiempo real.
• FUTR y INFOLas operaciones futuras, y las que se facilitan a título informativo, sin asiento.

¿Cómo codifica el banco el tipo de operación?

• ISO 20022Dominio, familia y subfamilia ISO.
• Codificación nacionalDominio FR, familia y código de operación CFONB.
• Código propietarioDebe documentarse, junto con su emisor.

¿Proporciona el banco el detalle de una transacción?

• NoSin enlace details.
• Para algunas transaccionesUn enlace details en la transacción indica que existe un detalle.

¿Expone el banco los titulares de una cuenta?

• NoSin enlace owners.
• PersonasUna lista identities, con fullName obligatorio.
• EmpresaUn bloque company.

¿Expone el banco la identidad del PSU conectado?

• NoSin enlace endUserIdentity.
• SíGET /end-user-identity, con fullName obligatorio, y nombre, apellido y tratamiento opcionales.

¿Expone el banco el descubierto autorizado?

• NoSin enlace overdrafts.
• SíGET /accounts/{id}/overdrafts, que solo devuelve allowedAmount.

¿Expone el banco la lista de beneficiarios de confianza?

• NoRespuesta 501, y el indicador isTrusted no debe aparecer nunca.
• SíGET /trusted-beneficiaries, con isTrusted en cada beneficiario.

¿Cuántos accesos al día acepta el banco sin el PSU?

• Cuatro en 24 horasEl mínimo regulatorio.
• MásSi el AISP y el banco lo acuerdan, con el consentimiento del PSU.

¿Qué token usa el CBPII para comprobar la disponibilidad de fondos?

• Con el PSUAuthorization code, OpenID Connect o CIBA, tras una SCA.
• Client credentialsCuando el PSU ha dado de alta previamente al CBPII en su banco.

¿La verificación se hace sobre una cuenta o sobre una tarjeta?

• CuentaIdentificada por su IBAN.
• TarjetaIdentificada por other, con CPAN, MPAN o TPAN.

¿Cómo confirma el PSU un pago?

• Enforced redirectEl PSU es redirigido al banco. Tras la SCA, el PISP obtiene un access token por authorization code y lo usa para su propia confirmación.
• DecoupledEl banco autentica al PSU en otro canal y llama directamente a la URL de retorno del PISP; después, el PISP confirma con su token client credentials.

¿Exige el banco una SCA para cancelar un pago?

• NoappliedAuthenticationApproach vale NONE y la cancelación es efectiva de inmediato.
• Simple redirectEl PSU es redirigido al banco para confirmar la cancelación.
• DecoupledEl banco pide que se confirme la cancelación en otro canal.

¿Qué tipos de solicitudes de pago acepta el banco?

• Transferencia únicaUna instrucción, un beneficiario.
• Varios beneficiariosCon la misma fecha de ejecución.
• Varias fechasPara el mismo beneficiario.
• Orden permanenteUna instrucción, un beneficiario, una frecuencia.

¿Qué instrumentos de pago acepta el banco?

• SCTTransferencia SEPA.
• SCT InstlocalInstrument con valor INST.
• Nacional en otra divisaCon códigos de declaración regulatoria.
• InternacionalCon fecha y lugar de nacimiento del acreedor.

¿Qué hace el banco cuando una transferencia inmediata no puede ejecutarse como inmediata?

• RechazoacceptInstantPaymentDowngrade vale false, que es el valor por defecto.
• DegradaciónSi el PISP lo acepta, el banco pasa a una SCT clásica y retira INST de localInstrument.

¿Proporciona el PISP la cuenta de cargo, y puede el banco cambiarla?

• Proporcionada por el PISPdebtorAccount presente.
• Elegida en el bancodebtorAccount ausente. La especificación no describe esta elección, que en principio se hace durante la autenticación.
• ModificableacceptDebtorAccountChange, que vale true por defecto, autoriza al banco a cambiarla.

¿Quién asume los gastos, y puede el banco cambiar esa elección?

• chargeBearerSLEV, SHAR, CRED o DEBT según el instrumento.
• acceptChargeHandlingChangeVale true por defecto y autoriza al banco a modificar el reparto.

¿Cuándo sale la transferencia, y qué hace el banco si la fecha no es posible?

• Lo antes posiblerequestedExecutionDate ausente.
• Fecha solicitadaLa fecha de cargo deseada.
• Fecha desplazadaEn un pago que no es una orden permanente, el banco puede pasar a la siguiente fecha posible.

¿Qué frecuencias y reglas de ejecución acepta el banco para una orden permanente?

• FrecuenciasDAIL, WEEK, TOWK, MNTH, TOMN, QUTR, SEMI, YEAR, o un subconjunto.
• Regla de ejecuciónFWNG o PREC, si la banca en línea la soporta.
• FinSin endDate, la orden no tiene fin.

¿Cuántas instrucciones puede contener una solicitud, y se contabilizan en lote?

• LímiteCada banco fija el máximo de numberOfTransactions.
• Batch bookingEl banco tiene su valor por defecto, y el PISP puede fijarlo.

¿Qué información de remesa acepta el banco?

• No estructuradaUna ocurrencia como máximo.
• EstructuradaUna ocurrencia como máximo.
• AmbasPueden coexistir.

¿Proporciona el PISP una URL de retorno distinta para el caso de fallo?

• Una sola URLsuccessfulReportUrl, que también se usa en caso de fallo.
• Dos URLsuccessfulReportUrl y unsuccessfulReportUrl.

¿Durante cuánto tiempo y de qué forma puede consultarse el estado de un pago?

• 30 díasEl mínimo que fija la especificación.
• Más tiempoSegún las reglas del banco.
• Endpoint de transaccionesGET /payment-requests/{id}/transactions, opcional, indicado por un enlace transactions.

¿Qué dice el banco al PISP sobre una transferencia no diferida que no es inmediata?

• Contabilizadabooking vale true.
• Fondos disponibles o noSi el sistema no puede contabilizar en el momento, booking vale false y fundsAvailability está presente.

¿Explica el banco por qué rechaza un pago?

• Motivo concretoUn código como AC01, AC04, AC06, AG01, AM02, AM04, AM18, FF01, FRAD o NOAS, entre otros.
• Sin motivoMS03, «No reason specified by the ASPSP».

¿Cómo publica el banco su implementación de la especificación?

• Archivo STET adaptadohost de personalización obligatoria, basePath y URL de autorización y de token personalizables.
• Desviaciones marcadasVersión de referencia en x-stet-psd2-api-reference-version, definiciones derivadas marcadas con x-original-definition.

¿Cómo responde el banco a una llamada a una función que no ofrece?

• 400El endpoint no está implementado en absoluto.
• 501Está implementado, pero no puede responder en este contexto.
• 405 y 406Método no soportado, o formato de respuesta no ofrecido.

¿Qué tipos de referencia de cuenta acepta el banco?

• IBANEl caso habitual.
• Otros esquemasBANK, BBAN, COID, SREN, SRET, NIDN, y también OAUT, CPAN, MPAN, TPAN, TBAN.

¿Qué reglas de transporte y de formato se aplican más allá del mínimo?

• TLS 1.2 como mínimoSe pueden añadir HSTS o PFS.
• HTTP 1.1 como mínimoSe permite una versión más reciente.
• FechasQuien genera la fecha elige la zona horaria (se recomienda UTC) y la precisión.

¿Prevé el banco un acceso de reserva si cae la interfaz específica?

• Mecanismo de reservaLos TPP usan la interfaz de clientes del banco, identificándose, hasta que se restablezca la interfaz específica (art. 33(4) de las RTS).
• ExenciónLa concede la autoridad competente, previa consulta a la EBA (art. 33(6)).

¿Qué cubre el entorno de pruebas del banco?

• Conexión y certificadosEstablecer el mTLS, intercambiar los certificados, recibir los mensajes de error.
• Flujos funcionalesAIS, PIS y confirmación de fondos, con datos de PSU ficticios.
• AutenticaciónTodos los procedimientos de autenticación que se ofrecen a los clientes.