Vendor management recibe una solicitud: senior Java para el equipo de la plataforma de pagos, liquidación T&M, inicio en dos semanas. El marco de contratación con el proveedor, de hace varios años, incluye un NDA, una cláusula de GDPR y la transferencia de derechos de autor. Compras pregunta por la tarifa. El equipo de riesgos de terceros pregunta otra cosa: si se trata de un "servicio de TIC" según DORA, si apoya una función crítica o importante, quién presta realmente el trabajo —el empleado del proveedor o el contratista B2B— y si el contrato incluye las disposiciones del artículo 30. Si las respuestas no están en los documentos, el inicio se pospone o el proveedor queda descartado.
El Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo, de 14 de diciembre de 2022, sobre la resiliencia operativa digital del sector financiero (DORA) es aplicable a partir del 17 de enero de 2025 (artículo 64). Las obligaciones del capítulo V, relativas a la gestión del riesgo de terceros proveedores de servicios de TIC, recaen en la entidad financiera. El banco o la entidad aseguradora sigue siendo plenamente responsable del cumplimiento incluso cuando subcontrata o externaliza servicios (artículo 28, apartado 1, letra a). En la práctica, sin embargo, estas obligaciones se trasladan al proveedor a través del contrato y la diligencia debida (due diligence). A continuación, analizamos cómo esto cambia de forma real el body leasing (cesión de personal).
¿Es el body leasing un servicio de TIC?
El artículo 3, punto 21, define los servicios de TIC como los servicios digitales y de datos prestados a través de sistemas de TIC a usuarios internos o externos de forma continua (con exclusión de los servicios de telefonía analógica tradicional). En una respuesta publicada en la base de datos de preguntas y respuestas (Q&A) de EIOPA (DORA030-2999), la Comisión Europea subraya que la definición tiene deliberadamente un ámbito amplio y que corresponde a la propia entidad financiera evaluar si un servicio específico constituye un servicio de TIC.
Una directriz práctica es la lista cerrada de tipos de servicios recogida en el anexo III del Reglamento de Ejecución (UE) 2024/2956 de la Comisión (plantillas del registro de información). Dicha lista incluye, entre otros, S01 – Gestión de proyectos de TIC, S02 – Desarrollo de TIC (análisis de negocio, diseño y desarrollo de software, pruebas), S04 – Gestión de la seguridad de las TIC y S15 – Asesoramiento en materia de TIC. Un especialista que escriba, pruebe o mantenga software de forma continuada en los sistemas del banco se engloba en estas categorías. La forma de facturación —por horas o a tanto alzado— no excluye el contrato del capítulo V.
⚡ Dos pruebas independientes: servicio de TIC y función crítica o importante
Prueba 1: servicio de TIC (artículo 3, punto 21) determina si el contrato se incluye en el registro de información y debe contener las disposiciones mínimas del artículo 30, apartado 2. Prueba 2: función crítica o importante (artículo 3, punto 22: función cuya perturbación menoscabaría materialmente el rendimiento financiero de la entidad financiera, la solidez o la continuidad de sus servicios y actividades, o el cumplimiento de las condiciones y obligaciones de su autorización) determina si se aplican los requisitos reforzados: estrategia de salida (artículo 28, apartado 8), evaluación del riesgo de concentración (artículo 29) y cláusulas adicionales del artículo 30, apartado 3. Ambas pruebas son realizadas por el banco, no por el proveedor.
Un mismo perfil —por ejemplo, un desarrollador backend sénior— puede quedar sujeto a dos regímenes diferentes. En el caso de un sistema de procesamiento de pagos, por lo general dará soporte a una función crítica o importante; en el caso de una herramienta interna de RR. HH., a menudo no. La tarifa por hora puede ser similar (hemos recopilado unos rangos orientativos en la comparativa de tarifas de body leasing de TI en 2026), pero el paquete contractual, el alcance de la diligencia debida (due diligence) y la inclusión en el registro ya no lo son.
La cadena: contratista B2B → proveedor → banco
El artículo 3, punto 18, define el riesgo de concentración de TIC asociado a proveedores terceros como el riesgo relacionado con los servicios prestados por proveedores terceros de servicios de TIC «o por sus subcontratistas». En el body leasing polaco, el especialista a menudo no es empleado del proveedor, sino un contratista B2B. Para el banco, esto supone un eslabón adicional en la cadena que debe ser visible.
En el caso de los servicios de apoyo a funciones críticas o importantes, el artículo 29, apartado 2, exige al banco que sopese los beneficios y los riesgos de la subcontratación ulterior —especialmente cuando el subcontratista está establecido en un tercer país— y que evalúe si unas cadenas largas o complejas pueden limitar su capacidad para supervisar las funciones y el control ejercido por el órgano de administración. Los elementos de esta evaluación se especifican en el Reglamento Delegado (UE) 2025/532 de la Comisión (RTS sobre subcontratación, aplicable desde el 22 de julio de 2025). Por su parte, el artículo 30, apartado 2, letra b), exige que se especifiquen en el contrato las regiones o los terceros países donde se van a prestar los servicios y a procesar los datos, así como la obligación de notificar previamente al banco cualquier cambio previsto. Un especialista que empiece a trabajar en remoto desde otro país constituye exactamente un cambio de esta naturaleza.
Antes de la celebración del contrato: artículos 28 y 29
El artículo 28(4) exige que, antes de celebrar un contrato, la entidad financiera: a) evalúe si el servicio da soporte a una función crítica o importante, b) compruebe si se cumplen las condiciones de supervisión para la celebración del contrato, c) identifique y evalúe los riesgos pertinentes, incluido el riesgo de concentración, d) realice la diligencia debida en relación con el proveedor y se asegure de que es adecuado, y e) identifique los conflictos de intereses.
El artículo 28(5) solo permite contratos con proveedores que apliquen normas de seguridad de la información adecuadas y, en el caso de funciones críticas o importantes, teniendo debidamente en cuenta las normas más actualizadas y de mayor calidad. El Reglamento no menciona explícitamente la norma ISO/IEC 27001 ni SOC 2. Las pruebas que se exigen se determinan en la propia política de la entidad, cuyo contenido para los servicios de apoyo a funciones críticas o importantes se especifica en el Reglamento Delegado (UE) 2024/1773 de la Comisión, de 13 de marzo de 2024 (RTS del artículo 28, apartado 10).
El artículo 29(1) añade la evaluación del riesgo de concentración: si el proveedor es fácilmente sustituible y si la entidad no acumula múltiples contratos de servicios de apoyo a funciones críticas o importantes en un único proveedor o en proveedores estrechamente vinculados. En la externalización de personal (body leasing), esta es una cuestión muy práctica: cuántas funciones críticas ocupa el mismo proveedor (vendor) y qué sucederá si este desaparece del mercado.
Registro de información (artículo 28, apartado 3)
La entidad financiera mantendrá y actualizará un registro de información sobre todos los acuerdos contractuales relativos a los servicios de TIC —no solo los críticos—, distinguiendo entre los contratos que den soporte a funciones críticas o importantes y los demás. Al menos una vez al año, informará a la autoridad competente, entre otros aspectos, sobre el número de nuevos acuerdos, las categorías de proveedores y los tipos de contratos, y pondrá a disposición el registro completo previa solicitud. La entidad informará a la autoridad competente con la debida antelación sobre cualquier acuerdo previsto relativo a una función crítica o importante.
Los modelos del registro se establecen en el Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024. En Polonia, la KNF (Polish Financial Supervision Authority) indicó el LEI como identificador obligatorio de la entidad que lleva el registro, y los registros se presentaron mediante el formulario SPR-PF-18 (la segunda fase en mayo de 2025 incluyó, entre otros, a las entidades que no habían presentado el registro antes del 28 de abril de 2025, así como los registros rechazados durante la verificación por parte de la AES). Según el resumen de obligaciones de información de la KNF, el acuerdo contractual previsto para servicios de apoyo a funciones críticas o importantes se notifica mediante el formulario SPR-PF-19 en un plazo de 14 días antes de la vinculación contractual.
Para el proveedor, esto se traduce en dos aspectos. El cuestionario de la entidad financiera solicitará los datos necesarios para el registro: identificador de la empresa, tipo de servicio de la lista S01–S19, ubicaciones de prestación y tratamiento de datos, y subcontratistas de la cadena. Y en el caso de las funciones críticas, empezar «a partir del lunes» no es realista si los trámites no se inician en paralelo con la contratación.
Estrategia de salida (artículo 28, apartado 8)
Para los servicios de TIC que den soporte a funciones críticas o importantes, la entidad financiera deberá disponer de estrategias de salida que tengan en cuenta, entre otros aspectos, el cese del proveedor, el deterioro de la calidad de los servicios, la interrupción de la actividad y la resolución del contrato en los supuestos contemplados en el artículo 28, apartado 7. La salida deberá ser posible sin interrupción de la actividad, sin menoscabo del cumplimiento de los requisitos normativos y sin perjuicio de la continuidad y la calidad de los servicios prestados a los clientes. Los planes de salida deberán ser exhaustivos, estar documentados, haber sido probados adecuadamente y ser objeto de revisiones periódicas.
En la externalización de personal (body leasing), el riesgo de salida adopta una forma muy concreta: la marcha de un perfil sénior clave, una baja médica, la rescisión de un contrato B2B. Por lo tanto, la entidad financiera espera un plan de sustitución (en qué plazo y de qué manera aparecerá un sucesor), un periodo de solapamiento (shadowing) y la documentación que permanece en la entidad —en el repositorio, la wiki y los tickets, y no en el ordenador personal del especialista—. Sin embargo, el artículo 28, apartado 8 va más allá de la mera sustitución de una persona: la entidad financiera debe ser capaz de finalizar toda la colaboración con el proveedor y asumir el trabajo por sí misma o transferirlo a otra entidad.
Artículo 30: lo que debe incluir el contrato
El artículo 30(1) exige una división clara y por escrito de los derechos y las obligaciones. El contrato completo, incluidos los acuerdos de nivel de servicio, constituirá un único documento en formato impreso o en otro formato duradero y accesible. El apartado 2 enumera los elementos mínimos de todo contrato de servicios de TIC, y el apartado 3, los elementos adicionales para los servicios que respaldan funciones críticas o importantes.
| Elemento | Apartado 2: todo contrato de servicios de TIC | Apartado 3: adicionalmente para funciones críticas o importantes |
|---|---|---|
| Descripción de los servicios | Descripción completa de las funciones y los servicios; información sobre si se permite la subcontratación de un servicio que respalda una función crítica o importante, y bajo qué condiciones (letra a) | – |
| Ubicaciones | Regiones o países donde se prestarán los servicios y donde se tratarán los datos, incluida su almacenamiento; notificación previa de cualquier cambio (letra b) | – |
| Protección de datos | Disponibilidad, autenticidad, integridad y confidencialidad de los datos, incluidos los datos personales (letra c) | – |
| Acceso a los datos y devolución | Acceso, recuperación y devolución de los datos en un formato fácilmente accesible en caso de insolvencia, reestructuración o cese de la actividad del proveedor, o de resolución del contrato (letra d) | – |
| Niveles de servicio | Descripciones de los niveles de servicio junto con sus actualizaciones (letra e) | Descripciones completas con objetivos cuantitativos y cualitativos precisos; medidas correctivas sin dilación indebida (letra a) |
| Incidentes | Asistencia en caso de incidente relacionado con los servicios, sin coste adicional o a un coste determinado de antemano (letra f) | Plazos de preaviso y obligaciones de información del proveedor, incluidos los acontecimientos que puedan afectar sustancialmente a la prestación de los servicios (letra b) |
| Autoridades | Plena cooperación con las autoridades competentes y con las autoridades de resolución (letra g) | – |
| Resolución del contrato | Derechos de resolución del contrato y plazos mínimos de preaviso (letra h) | – |
| Formación | Condiciones para la participación del proveedor en los programas de concienciación y formación de la entidad (letra i, artículo 13(6)) | – |
| Continuidad de actividad | – | Implementación y pruebas de planes de continuidad de negocio y medidas de seguridad de las TIC (letra c) |
| TLPT | – | Participación y plena cooperación en las pruebas de penetración basadas en amenazas (letra d, artículos 26-27) |
| Auditoría | – | Derechos ilimitados de acceso, inspección y auditoría para la entidad, un tercero designado y la autoridad (letra e) |
| Salida | – | Estrategias de salida con un período de transición obligatorio en el que el proveedor siga prestando los servicios (letra f) |
Hay dos aspectos que es fácil pasar por alto. El derecho de auditoría del artículo 30(3)(e) debe ser ejecutable y no puede verse limitado por ningún otro contrato o política interna del proveedor. Por su parte, la obligación de prestar asistencia en caso de incidente (artículo 30(2)(f)) se aplica a cualquier contrato de servicios de TIC, no solo a los críticos. En nuestros artículos sobre la negociación de contratos con empresas de desarrollo de software y el body leasing transparente describimos cómo trasladar estos requisitos a un contrato marco y a una SOW sin perder el control sobre la propiedad intelectual y los costes.
Incidentes de TIC: quién notifica qué (artículos 17 a 19)
El proceso de gestión de incidentes (artículo 17), su clasificación (artículo 18) y la notificación de incidentes graves relacionados con las TIC a la autoridad competente (artículo 19) son obligaciones de la entidad financiera. El artículo 19(4) establece tres etapas: la notificación inicial, el informe intermedio y el informe final. El banco puede externalizar la elaboración de informes a un tercero, pero sigue siendo plenamente responsable de ellos (artículo 19(5)). En Polonia, los incidentes graves de TIC se notifican a través del sistema de la KNF (Polish Financial Supervision Authority) disponible en csirt.knf.gov.pl.
Por tanto, la empresa de externalización de personal (body leasing) no notifica el incidente a la KNF en nombre del banco. Su tarea consiste en notificar inmediatamente al banco cuando un especialista detecte un incidente relacionado con el servicio o contribuya a él, proporcionar los hechos necesarios para la clasificación y prestar asistencia con arreglo al artículo 30(2)(f). En el contrato y en la incorporación (onboarding) del especialista debe establecerse una vía específica: a quién notificar, a través de qué canal y en qué plazo. Para los roles estrictamente de seguridad, véase también body leasing de especialistas en ciberseguridad.
Lista de verificación de diligencia debida del proveedor de especialistas en TI
La siguiente lista organiza las preguntas que vale la pena hacer al proveedor antes de firmar el contrato. Es un conjunto de control de trabajo y no un sustituto de la política del banco.
| Qué comprobar | Qué esperar del proveedor | Base |
|---|---|---|
| Si es un servicio TIC y de qué tipo | Descripción del rol, de los sistemas y del modo de trabajo; asignación al tipo S01–S19 | Artículo 3, punto 21; ITS 2024/2956, anexo III |
| Si el servicio respalda una función crítica o importante | Clasifica al banco; el proveedor declara su disposición a aceptar las cláusulas del apartado 3 | Artículo 28, apartado 4, letra a); artículo 3, punto 22 |
| Cadena de subcontratación | Forma de colaboración con el especialista (empleo en plantilla o B2B), entidad, país; normas para la ulterior subcontratación | Artículo 29, apartado 2; artículo 30, apartado 2, letra a); RTS 2025/532 |
| Ubicaciones | País de trabajo y de tratamiento de datos; procedimiento para notificar cambios | Artículo 30, apartado 2, letra b) |
| Seguridad de la información | Política de seguridad, NDA, normas de acceso; trabajo exclusivamente en entornos aceptados por el banco | Artículo 28, apartado 5; artículo 30, apartado 2, letra c) |
| Datos para el registro de información | Identificador de la empresa (p. ej., LEI), datos registrales, posición en la cadena | Artículo 28, apartado 3; ITS 2024/2956 |
| Incidentes | Canal de notificación; coste de la asistencia incluido en el precio o fijado de antemano | Artículo 30, apartado 2, letra f); artículos 17 a 19 |
| Formación | Consentimiento para la participación de los especialistas en los programas de concienciación del banco | Artículo 13, apartado 6; artículo 30, apartado 2, letra i) |
| Sustitución y conocimiento | Plan de sustitución, período de solapamiento, documentación por parte del banco | Artículo 28, apartado 8 |
| Auditoría, TLPT, salida | Disposición para auditorías y pruebas; prestación de servicios durante el período de transición | Artículo 28, apartado 6; artículo 30, apartado 3, letras d) a f) |
Body leasing, team leasing, outsourcing: dónde sitúa DORA los acentos
DORA se aplica a cada uno de estos modelos. Se diferencian en quién es responsable del resultado del trabajo, cómo se presenta la concentración y qué significa en la práctica la salida. Los detalles de los modelos se describen en las páginas de modelos de colaboración y leasing de equipos de TI.
| Modelo | Quién dirige el trabajo | Riesgo de concentración (Artículo 29) | Contrato (Artículo 30) | Salida en la práctica |
|---|---|---|---|---|
| Body leasing / T&M | El banco; el proveedor es responsable de la persona, la cadena y la sustitución | Aumenta cuando un solo proveedor ocupa múltiples roles críticos | Siempre el apartado 2; el apartado 3 cuando el papel apoya una función crítica o importante | Sustitución de la persona o asunción del rol por parte del banco |
| Team leasing | El proveedor organiza la composición y el ritmo del trabajo; el banco establece los objetivos | Más alto: múltiples roles en un solo proveedor (Artículo 29, apartado 1, letra b) | Apartado 2; en el caso de función crítica, apartado 3 (SLA, auditoría, TLPT, periodo de transición) | Transferencia de todo el equipo y del conocimiento |
| Outsourcing / managed service | El proveedor es responsable del resultado o del mantenimiento del servicio | Alto con baja sustituibilidad y subcontratistas en terceros países | Apartado 2 y, por lo general, apartado 3 | Migración del servicio y de los datos a otro proveedor o in-house |
Antipatrones
- «Es solo alquiler de personal, DORA se aplica a la nube». La definición del artículo 3, punto 21, y los tipos S01–S19 abarcan el desarrollo de software, las pruebas, la seguridad y la consultoría de TIC. La facturación por tiempo y materiales (T&M) no cambia nada en este aspecto.
- Cadena B2B oculta. La agencia firma un contrato marco, pero en el proyecto trabaja el contratista de otro intermediario más. El banco no sabe quién presta el servicio, por lo que no puede evaluar de forma fiable la subcontratación (artículo 29, apartado 2) ni cumplimentar correctamente el registro.
- Falta de plan de contingencia. El conocimiento sobre la canalización de despliegue reside únicamente en la cabeza de un solo desarrollador sénior. Para las funciones críticas, el artículo 28, apartado 8, y el artículo 30, apartado 3, letras c) y f), exigen planes de contingencia y un periodo de transición; la declaración de «harémos todo lo posible» no los sustituye.
- Auditoría solo sobre el papel. La cláusula de auditoría figura en el anexo, pero la política interna del proveedor no contempla permitir el acceso a un auditor. El artículo 30, apartado 3, letra e), exige que el ejercicio de estos derechos no esté limitado por otras disposiciones.
Cómo trabaja Commoditech
Commoditech desde 2012 suministra especialistas de TI en el modelo de body leasing y contratación. No clasificamos la función por el banco ni llevamos su registro; estas son obligaciones de la entidad financiera. Nuestro papel es ser un proveedor que se pueda evaluar de manera fiable, incluir en el registro y auditar:
- Margen transparente: el cliente sabe qué parte de la tarifa va al especialista y qué parte al proveedor (cómo funciona el body leasing transparente).
- Transmisión del 100% de los derechos de autor patrimoniales del código generado al cliente.
- Especialistas verificados: verificación técnica antes de presentar el perfil.
- Cadena de subcontratación transparente: información sobre la forma de cooperación y el país de trabajo del especialista, así como disponibilidad para incluir una cláusula de prohibición de ulteriores subcontrataciones sin el consentimiento del banco.
- Disponibilidad para las cláusulas del artículo 30: el apartado 2 en cada contrato, el apartado 3 allí donde el banco califique el servicio como de apoyo a una función crítica o importante.
- Plan de sustitución y transferencia de conocimiento estipulado en el contrato y no declarado verbalmente.
- Cooperación en auditorías y pruebas realizadas por el banco, una entidad designada por este o una autoridad de supervisión.
No declaramos certificados que no tenemos. Si la política del banco exige al proveedor una certificación concreta, lo hablamos abiertamente en la fase de cualificación. Si están preparando una solicitud de especialistas para un entorno sujeto a DORA, escríbanos; empezaremos por la lista de datos necesarios para su registro y due diligence.
🛠️ De la práctica: cómo es una conversación sobre DORA al encargar un especialista
Un escenario típico, sin nombres ni cifras. El departamento de compras envía una solicitud de un desarrollador backend sénior para un sistema que el banco clasifica como de apoyo a una función crítica o importante. En paralelo, el equipo de riesgo de terceros (third-party risk) envía un cuestionario: tipo de servicio de TIC, ubicaciones de prestación y procesamiento de datos, lista de subcontratistas, vía de notificación de incidentes, derechos de auditoría, periodo de transición en la salida, participación en formación de seguridad.
La respuesta «trabajamos en T&M, el resto como en el marco contractual» suele terminar la conversación antes de que empiece la verificación de los candidatos. Un proveedor que muestra de inmediato la cadena (p. ej., contratista B2B de Polonia, sin ulteriores subcontrataciones), el lugar de trabajo, las cláusulas listas del artículo 30, apartado 3 y el plan de sustitución en la SOW pasa a la evaluación de competencias propiamente dicha. DORA no sustituye la conversación técnica; establece el filtro previo sin el cual dicha conversación no comienza.
FAQ
¿Cada contrato de body leasing de TI con un banco constituye un servicio de TICs según DORA?
La evaluación corresponde a la entidad financiera, y la definición del Artículo 3(21) es deliberadamente amplia. El anexo III del ITS 2024/2956 incluye, entre otros, el desarrollo de TICs (S02), la seguridad de TICs (S04) y la consultoría de TICs (S15), por lo que el trabajo de un especialista en los sistemas bancarios de forma continuada suele encajar en dicha definición.
¿Cuándo un contrato de T&M para una sola persona requiere las cláusulas del Artículo 30(3)?
Cuando el servicio respalda una función crítica o importante (Artículo 3(22)). El número de personas no importa: el apartado 2 se aplica a todo contrato de servicios de TICs, y el apartado 3 se añade siempre que el banco califique la función como crítica o importante.
¿Es un contratista B2B del proveedor un subcontratista sobre el cual el banco debe estar informado?
Si es él quien presta efectivamente el servicio, sí. El Artículo 3(18) abarca el riesgo asociado a los subcontratistas del proveedor, y en el caso de funciones críticas o importantes, el Artículo 29(2), el Artículo 30(2)(a) y el RTS 2025/532 exigen la evaluación y regulación de la subcontratación.
¿Quién notifica un incidente grave relacionado con las TICs a la KNF (Polish Financial Supervision Authority): el banco o la empresa de body leasing?
La entidad financiera (Artículo 19), a través del sistema de la KNF en csirt.knf.gov.pl. El proveedor avisa al banco y ayuda en la gestión del incidente (Artículo 30(2)(f)). El banco puede encargar la presentación de informes a un tercero, pero la responsabilidad recae en él (Artículo 19(5)).
¿Debe el proveedor de especialistas contar con la norma ISO 27001 para colaborar con un banco?
DORA no exige un certificado específico. El Artículo 28(5) se refiere a normas adecuadas de seguridad de la información, y las expectativas detalladas las determina la política del banco, la cual puede exigir un certificado, una auditoría u otras evidencias. La falta de cualquier norma de seguridad documentada y de disponibilidad para auditorías excluye en la práctica al proveedor.
Fuentes
- Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA) – EUR-Lex
- Reglamento de Ejecución (UE) 2024/2956 de la Comisión (plantillas del registro de información, anexo III – tipos de servicios de TIC) – EUR-Lex
- Reglamento Delegado (UE) 2024/1773 de la Comisión (RTS – política de contratos relativos a servicios de TIC que apoyan funciones críticas o importantes) – EUR-Lex
- Reglamento Delegado (UE) 2025/532 de la Comisión (RTS – subcontratación de servicios de TIC que apoyan funciones críticas o importantes) – EUR-Lex; EBA
- KNF (Autoridad de Supervisión Financiera de Polonia) – DORA; registro de información y LEI; segunda fase de remisión de los registros (SPR-PF-18); resumen de obligaciones de presentación de informes; sistemas DORA y notificación de incidentes
- EIOPA – Q&A DORA030-2999 (definición de servicios de TIC); DORA
- EBA – DORA
- ESMA – DORA
El presente artículo tiene carácter meramente informativo y no constituye asesoramiento jurídico. La clasificación del servicio de TIC y de la función crítica o importante, el contenido del contrato y la inscripción en el registro dependen de las circunstancias específicas y de la política de la entidad financiera. El texto vinculante es el del reglamento, los actos de ejecución y los criterios de la autoridad de supervisión (en Polonia, la KNF).