Publicado el 10 de diciembre de 2023 por Editor
La semana pasada, el Grupo de Trabajo de Modernización Regulatoria de EE. UU. (RMWG) de XBRL presentó una carta de comentarios en respuesta a la regla propuesta por la Comisión de Bolsa y Valores (SEC), EDGAR Filer Access and Account Management, también conocida como ‘EDGAR Next’.
La carta de comentarios profundiza en aspectos cruciales, incluida la necesidad de funcionalidad API adicional, preocupaciones sobre protocolos complejos que podrían obstaculizar las presentaciones oportunas y la necesidad de una capacitación adecuada y un tiempo de transición para los registrantes y desarrolladores de aplicaciones.
Las modificaciones propuestas tienen como objetivo mejorar el acceso y la gestión de las cuentas en EDGAR, denominadas colectivamente «EDGAR Next». Esto incluye requisitos para que los declarantes autoricen y mantengan a personas designadas como administradores de cuentas y la introducción de API opcionales para la comunicación de máquina a máquina con EDGAR.
La carta de comentarios proporciona algunas ideas sobre estos cambios propuestos, enfatizando consideraciones prácticas y desafíos potenciales.
Para obtener una comprensión detallada de la respuesta de XBRL US y las enmiendas propuestas por la SEC, lea la carta aquí y lea la propuesta de regla original aquí.
Estimada Sra. Countryman:
RE: Acceso al Declarante EDGAR y Gestión de Cuentas, Número de Expediente S7-15-23
Gracias por la oportunidad de comentar sobre los posibles cambios en el Sistema de Acceso y Gestión de Cuentas de Declarantes de EDGAR, también conocido como EDGAR Next.
XBRL US es una organización de estándares sin fines de lucro, con la misión de mejorar la eficiencia y la calidad de los informes en los EE. UU. mediante la promoción de la adopción de estándares de informes comerciales. XBRL US es una jurisdicción de XBRL International, el consorcio sin ánimo de lucro responsable de desarrollar y mantener las especificaciones técnicas de eXtensible Business Reporting Language (XBRL). XBRL es un estándar de datos libre y abierto ampliamente utilizado en los Estados Unidos, y en todo el mundo, para la presentación de informes por parte de empresas públicas y privadas, así como de bancos y agencias gubernamentales.
Esta carta fue preparada por el Grupo de Trabajo de Modernización Regulatoria de XBRL US, un grupo de 14 agentes de presentación y proveedores de solicitudes1, que brindan servicios de informes y solicitudes a la mayoría de los solicitantes de registro de la SEC. Nuestras principales preocupaciones con la propuesta se refieren a 1) la necesidad de una funcionalidad adicional de la API para mantener informados a los administradores y usuarios y limitar la pérdida de información cuando caduquen los tokens; 2) protocolos complejos introducidos por EDGAR Next que podrían crear barreras para la presentación oportuna; y 3) la necesidad de capacitación y un calendario de transición apropiados para que los registratarios y los desarrolladores de aplicaciones realicen la transición. Esta carta también aborda preguntas específicas planteadas en la solicitud de comentarios, como se indica a continuación.
Credenciales de cuenta individual
1. ¿Deberíamos exigir el uso de credenciales de cuentas individuales, como se propone en la Regla 10(d)(1), y la autenticación multifactorial para todos los declarantes existentes, las personas que actúen en su nombre y los solicitantes de acceso a EDGAR?
Respuesta de XBRL US: La autenticación multifactorial es un paso adelante en el aumento de la seguridad de EDGAR y se ha convertido en un estándar para la mayoría de las empresas. Sin embargo, solo es necesario administrar el panel de administración de archivadores y obtener los tokens de archivador y usuario, lo que podría dejar el sistema vulnerable a una entidad maliciosa durante 30 días si obtuvieran acceso a estos tokens.
2. ¿Tiene la comunidad de solicitantes experiencia en la obtención de credenciales de cuentas de proveedores de servicios externos, incluidos o similares a Login.gov que la Comisión debería considerar? En caso afirmativo, ¿qué proveedores de servicios de terceros y qué experiencia? ¿El uso de proveedores de servicios externos daría lugar a algún problema de seguridad para los declarantes individuales o morales?
Respuesta de XBRL US: Auth0 es un servicio de autenticación utilizado por algunas aplicaciones que la Comisión podría tener en cuenta.
3. ¿El uso de credenciales de cuentas individuales daría lugar a alguna preocupación con respecto a los costos, la confusión o la complejidad para los contribuyentes individuales o de entidades? ¿Existen preocupaciones específicas para los declarantes individuales o morales que presentan declaraciones con respecto a más de una empresa en cuestión (por ejemplo, un declarante individual que es miembro de la junta directiva de más de una empresa)? Si es así, ¿qué preocupa? Por favor, sea específico.
Respuesta de XBRL US: Los declarantes individuales que pueden ser miembros de la junta directiva no están acostumbrados a gestionar el proceso EDGAR. Las situaciones en las que una persona está en varios tableros podrían generar confusión en torno a la administración adicional involucrada en el mantenimiento de códigos de archivo activos. Considere el siguiente escenario:
● El miembro de la Junta Directiva de la Compañía A otorga autoridad administrativa al secretario Corporativo de la Compañía A para su CIK individual
● Más tarde, este miembro de la junta se une a la junta directiva de la empresa B. El secretario corporativo de la empresa A delega la autoridad de presentación del miembro de la junta directiva al secretario corporativo de la empresa B para las transacciones con información privilegiada asociadas con la empresa B.
● Más tarde, el miembro de la junta deja la junta directiva de la empresa A, lo que crea una situación en la que el secretario corporativo de la empresa A debe gestionar la revisión/renovación anual del miembro de la junta o perseguir al miembro de la junta para que haga la transición de la administración de su CIK a la empresa B o a alguna otra entidad.
Este tipo de situación aumenta el riesgo de que la revisión/renovación no se lleve a cabo y la empresa B no pueda presentar la solicitud en nombre del miembro de la junta. La gestión de las tareas administrativas confundirá a las personas que no están acostumbradas a gestionar las credenciales de EDGAR y creemos que esta confusión aumentaría el riesgo de no cumplir con los plazos de presentación.
Recomendamos que el Panel de Archivadores permita a un Administrador de Presentación solicitar la delegación de otro declarante. Esa solicitud (incluido el texto explicativo proporcionado por el solicitante) se enviaría desde el sistema EDGAR a los administradores de la presentación del otro declarante.
Roles individuales: Administrador de cuentas, Usuario, Administrador técnico
4. ¿Deberíamos agregar un rol de administrador de cuentas requerido a EDGAR, como se establece en la Regla 10(d) propuesta? Si no es así, ¿por qué no?
Respuesta de XBRL US: Sí, el administrador de la cuenta también debe tener acceso completo a todas las funciones de administración de ficheros, incluida la capacidad de generar y administrar tokens de archivadores.
5. Como se indica en la propuesta de Regla 10.d), se necesitarían al menos dos administradores de cuentas para las entidades declarantes (que no sean sociedades unipersonales) y un administrador de cuentas para los declarantes individuales y las sociedades unipersonales. ¿Son apropiados estos números mínimos de administradores de cuentas? Si no es así, ¿qué número mínimo de administradores de cuentas sería apropiado? ¿Debería exigirse a los contribuyentes individuales y a las empresas unipersonales que tengan más de un administrador de cuenta? Si es así, ¿por qué?
Respuesta de XBRL US: Dos administradores son apropiados, pero debe haber un mecanismo en el panel de gestión de archivos en el que la empresa (por ejemplo, el administrador técnico) pueda identificar y ponerse en contacto con sus administradores en caso de que haya cambios dentro de la empresa y/o cambios en los códigos de cuenta. Puede haber varias partes accediendo al panel y sería útil poder identificar rápidamente a los administradores principales.
6. ¿Se debe permitir que los administradores de cuentas agreguen y/o eliminen a otros administradores de cuentas sin el consentimiento del declarante? Si es así, ¿por qué? Si no se requiere el consentimiento del declarante, ¿se debe notificar al declarante cuando se agrega o elimina un nuevo administrador de cuenta?
Respuesta de XBRL US: Sí, los administradores de cuentas deben tener este nivel de autoridad. Se debe permitir la adición sin consentimiento, para gestionar las emergencias que puedan surgir, lo que podría poner en riesgo los plazos de presentación. Un proceso de aprobación en el sitio EDGAR Next requerirá un rol adicional por encima del administrador e introduce otro obstáculo potencial para una acción rápida. Un proceso de aprobación fuera de línea será lento y puede requerir la transmisión y revisión de documentación notariada. Entendemos que todavía existe un riesgo potencial con los actores deshonestos en las empresas, pero las empresas están gestionando el riesgo de los empleados de actores deshonestos hoy en día y se les debe dejar que gestionen ese problema con respecto a EDGAR Next. Además de exigir un mínimo de dos administradores, como en nuestra respuesta a la pregunta 5, creemos que la notificación es apropiada. Alertar a otros administradores cuando se agrega o se va un administrador mejorará la capacidad de la red para reaccionar a los cambios del administrador.
7. ¿Debería exigirse que un administrador de cuenta complete y presente el ID del formulario de un posible declarante, según lo establecido en la Regla 10(b) propuesta? De no ser así, ¿cuáles serían las ventajas y desventajas de permitir que una persona que no es administradora de cuentas complete y envíe un ID de formulario en nombre de un solicitante? Por favor, sea específico.
Respuesta de XBRL US: También se debe permitir que un usuario envíe un ID de formulario en caso de que el administrador de la cuenta no esté disponible, siempre y cuando los dos administradores de la cuenta estén introducidos en el ID del formulario.
8. En la propuesta de Regla 10.d), cada declarante, por conducto de sus administradores de cuentas, estaría obligado a confirmar anualmente la exactitud de la información del declarante en el tablero; mantener información precisa y actualizada sobre EDGAR con respecto a la cuenta del declarante; y mantener de forma segura la información relevante para la capacidad de acceder a la cuenta EDGAR del declarante, incluido, entre otros, el acceso a través de cualquier API EDGAR. ¿Debería introducirse algún cambio o aclaración en las responsabilidades propuestas de los declarantes que deben llevar a cabo los administradores de cuentas en la Regla 10 propuesta? En caso afirmativo, ¿cómo y por qué deben hacerse esos cambios o aclaraciones? ¿Debería proporcionarse alguna orientación con respecto a cualquiera de estas responsabilidades y, en caso afirmativo, cómo y por qué?
Respuesta de XBRL US: Apoyamos este enfoque, aunque en el caso de que el administrador de la cuenta no actualice la información del declarante en el panel de control dentro del período de tiempo asignado, es posible que la Comisión desee desactivar la cuenta. Algunos emisores pueden presentar la declaración con poca frecuencia, por ejemplo, los declarantes de la Sección 16 del operador propietario que declara.
10. ¿Debería introducirse algún cambio en el alcance del requisito de confirmación anual propuesto establecido en la Regla 10 propuesta? ¿Por qué? ¿La confirmación debe realizarse anualmente, con más frecuencia o con menos frecuencia? ¿Por qué? Como se contempla actualmente como parte de EDGAR Next, en el caso de que no se cumpla con el requisito de confirmación anual propuesto, ¿debería haber un período de gracia para que los administradores de la cuenta satisfagan los requisitos de confirmación antes de que se desactive la cuenta? ¿Cuánto tiempo debería durar este período de gracia, si se adopta? Independientemente de si se proporciona un período de gracia, en caso de que el incumplimiento del requisito de confirmación anual propuesto resulte en la desactivación de la cuenta con la eliminación de las personas autorizadas en el tablero para el declarante, como se discutió anteriormente, o alternativamente, sería más apropiada una suspensión temporal del acceso a EDGAR sin la eliminación de ninguna de las personas autorizadas en el tablero para el declarante, hasta que alguno de los administradores de cuentas enumerados cumpliera con el requisito de confirmación? ¿Por qué? ¿Cuánto tiempo debe durar la suspensión temporal descrita, en caso de ser adoptada? Por otra parte, si el incumplimiento de los requisitos de confirmación anual propuestos diera lugar a la desactivación de la cuenta con la eliminación de las personas autorizadas en el panel de control del declarante, como se ha comentado anteriormente, ¿deberían eliminarse también del panel las entidades delegadas y los declarantes delegantes? ¿Por qué sí o por qué no?
Respuesta de XBRL US: El requisito de confirmación anual impone una carga adicional a los registrantes que parece ser innecesaria, dado que la eliminación de un usuario y/o token invalidará el acceso al sistema EDGAR por sí solo.
Tal como está redactada, la propuesta establece que los declarantes serán alertados antes de la fecha límite para su confirmación anual. Alentamos a la Comisión a considerar la posibilidad de imponer una suspensión temporal de 2 semanas si no se cumple el requisito de confirmación antes de desactivar y eliminar información de una cuenta existente. Eso le daría tiempo al declarante para reactivar y guardar la información enviada anteriormente si decide hacerlo.
Recomendamos no dejar que el token caduque nunca o, como mínimo, establecer un tiempo más largo para el período de vencimiento del token. Si la Comisión determina que el token debe caducar, pedimos que en caso de que caduque, el token se suspenda con la posibilidad de habilitarlo más tarde (sin borrar todos los datos de la cuenta). También sugerimos que la Comisión brinde a los usuarios la posibilidad de ver información sobre el token, por ejemplo, cuál es la próxima fecha de vencimiento. Esto podría ejecutarse a través de una API que proporcione visibilidad sobre si el token debería funcionar y, si no es funcional, una explicación de por qué no funciona.
11. ¿El requisito de confirmación anual crearía alguna carga adicional para los declarantes en comparación con el requisito anual actual de actualización de contraseña de EDGAR? En caso afirmativo, ¿hay alguna mejora en el requisito de confirmación anual propuesto que reduzca la carga para los declarantes? Por otra parte, ¿existe alguna preocupación particular para los declarantes que solo pueden participar en presentaciones ocasionales, como los declarantes de conformidad con la sección 16 de la Ley de Intercambio de Valores de 1934 que pueden hacer presentaciones esporádicas de los Formularios 3, 4 y 5 menos de una vez al año? De ser así, ¿en qué medida esas preocupaciones se verían implicadas en la propuesta, dado que actualmente los declarantes deben cambiar su contraseña anualmente o se desactiva su acceso a EDGAR?
Respuesta de XBRL US: El requisito de confirmación anual supondrá una carga adicional significativa para los declarantes que utilicen las credenciales de la SEC de un agente declarante, en particular para aquellos declarantes que presenten comunicaciones esporádicas, como los declarantes de la Sección 16.
12. ¿Hay alguna consideración con respecto al requisito de confirmación anual que sea específica para los declarantes individuales o morales que realizan presentaciones con respecto a más de una empresa sujeta (por ejemplo, un declarante individual que es miembro de la junta directiva de más de una empresa)? ¿Debería diferir el requisito de confirmación para dichos declarantes? Si es así, ¿por qué?
Respuesta de XBRL en EE. UU.: El plazo de inicio de sesión de 30 días será un problema importante, en particular para los declarantes que presentan solicitudes con poca frecuencia, como los declarantes de la Sección 16.
13. ¿Deberíamos añadir un rol de usuario a EDGAR? De no ser así, ¿cómo abordaríamos nuestras preocupaciones de política con respecto a la identificación y autorización de las personas que hacen presentaciones en nombre del declarante? ¿Es apropiado un límite de 500 usuarios autorizados por declarante, o ese número debe aumentarse o disminuirse? ¿Deberían los administradores de cuentas poder agregar usuarios solo para una presentación específica o durante un período de tiempo específico, después del cual la autorización del usuario expira automáticamente? ¿Debería hacerse algún cambio o aclaración en el alcance de la autoridad de los usuarios como parte de EDGAR Next? En caso afirmativo, ¿cómo y por qué debería ser diferente el ámbito de autoridad de los usuarios, o cómo podrían aclararse las tareas dentro del ámbito de autoridad de los usuarios?
Respuesta de XBRL US: Creemos que el límite de 500 usuarios autorizados por declarante es suficiente.
14. ¿Deberíamos añadir una función de administrador técnico al EDGAR, tal como se establece en la Regla 10? d) propuesta? De no ser así, ¿cómo abordaríamos nuestras preocupaciones de política con respecto a la identificación y autorización de las personas que administrarían las API del declarante?
Respuesta de XBRL US: Basándonos en el lenguaje de la propuesta, no entendemos la diferencia entre un administrador técnico y un administrador de cuentas. La adición de un rol de administrador técnico puede complicar aún más el proceso. Podría ser útil si este rol fuera opcional y se pudiera combinar con el administrador de la cuenta si la empresa así lo decidiera, por ejemplo, si el administrador de la cuenta pudiera generar el token del archivador.
16. ¿Con qué fines, en su caso, necesitarían los declarantes acceder al tablero cuando la funcionalidad de presentación de EDGAR no estuviera disponible? Si el tablero se pusiera a disposición de los declarantes durante un período de tiempo fuera del horario de atención de EDGAR, además de durante el horario de atención de EDGAR, ¿se verían afectados los declarantes por la falta de disponibilidad de asistencia telefónica y por correo electrónico para los declarantes y las capacidades de presentación de EDGAR durante ese período de tiempo? ¿Cómo se verían afectados? Por favor, sea específico.
Respuesta de XBRL EE. UU.: Los emisores privados extranjeros o incluso otras jurisdicciones como Hawái operan fuera del horario tradicional de presentación de EDGAR. Se enfrentarán a desafíos por la falta de disponibilidad de soporte telefónico y por correo electrónico para los declarantes y las capacidades de presentación de EDGAR durante las horas que no son de EDGAR.
Además, según la propuesta de EDGAR Next, un token de usuario puede ser desactivado si el declarante no inicia sesión dentro de un plazo de 30 días. Como se propone actualmente, los agentes de presentación no sabrán si un token ya no está activo. La capacidad de restaurar el acceso a un usuario inactivo durante las horas en las que no se presenta la solicitud sería fundamental para permitir la presentación de solicitudes a primera hora de la mañana. Consulte a continuación, en la sección sobre API, nuestra recomendación de que se proporcione una API que brinde a los agentes de presentación y a los declarantes la capacidad de «ver» el estado actual de un token para evitar posibles problemas.
Entidades delegadas
18. ¿Deberían los administradores de cuentas poder delegar la autoridad de presentación a cualquier declarante de EDGAR (y eliminar dicha delegación)? ¿Los comentaristas tienen alguna preocupación con respecto a la función de delegación o alguna modificación sugerida? Por ejemplo, ¿debería limitarse la delegación a los declarantes de EDGAR que seleccionaron «agente de presentación» como el tipo de cuenta en el ID del formulario al abrir la cuenta? ¿O debería permitirse la delegación a cualquier cuenta de EDGAR, como se ha propuesto? ¿Por qué?
Respuesta de XBRL US: Los administradores de cuentas deberían poder delegar la autoridad de presentación a los proveedores. Los proveedores deben poder solicitar de forma proactiva la delegación del registrante y recibir confirmación en el sitio. Las confirmaciones para el agente/proveedor de presentación deben poder ser aprobadas automáticamente por el registrante.
Además, se recomienda que se ponga a disposición una función de delegación masiva para ayudar a los declarantes que tienen varios CIK, y que esta capacidad se permita mediante una sola solicitud de invitación (en lugar de varias invitaciones para varios CIK).
Además, recomendamos que cualquier agente de presentación CIK que haya realizado una presentación para un registrante durante los últimos 12 a 18 meses se agregue automáticamente como entidad delegada en la inscripción inicial.
19. ¿Abordaría el marco de delegación de EDGAR Next las preocupaciones planteadas por los comentaristas sobre el impacto que los cambios contemplados en EDGAR Next tendrían en los declarantes individuales de funcionarios y directores de conformidad con la sección 16 de la Ley de Bolsa, a la luz del hecho de que los declarantes de funcionarios y directores individuales podrían delegar la autoridad para presentar en su nombre a cualquier empresa relacionada? bufetes de abogados o agentes de archivo? ¿Por qué sí o por qué no?
Respuesta de XBRL US: Sí, la capacidad de delegar autoridad ayudaría a los declarantes poco frecuentes, como los declarantes de la Sección 16.
20. ¿Debería hacerse algún cambio en la autoridad de los administradores delegados y los usuarios delegados en EDGAR Next?
Respuesta de XBRL US: Sugerimos agregar el privilegio para que los administradores delegados administren los tokens de archivo de las entidades delegantes.
21. ¿Hay alguna situación en la que se pueda racionalizar el marco de delegación de EDGAR Next?
Respuesta de XBRL US: Como se señaló en nuestra respuesta a la pregunta 18, los proveedores deberían poder asumir actividades de presentación y poder solicitar de forma proactiva la delegación al solicitante de registro y obtener la confirmación de la delegación a través del sitio.
Interfaces de programación de aplicaciones
23. ¿Deberíamos agregar otra información de EDGAR a la que se pueda acceder a través de API y, de ser así, por qué? Clasifique en términos de prioridad cualquier información adicional que le gustaría que se agregara, y también calcule cuánto uso cree que recibiría esa API de información (por ejemplo, en posibles visitas por día).
Respuesta de XBRL US: Todas las funciones proporcionadas en la sección Recuperar/editar datos del sitio de EDGAR deben tener una implementación de API equivalente, por ejemplo, para ver los saldos de las comisiones y la actividad de la cuenta, y para proporcionar información sobre el estado del token. Se necesita acceso completo a la API para el panel de administración del archivador, por ejemplo, confirmación anual, token, etc. para administrar el tablero de manera eficiente. Se deben proporcionar API que permitan a los usuarios confirmar que tienen autoridad para presentar una solicitud en el CIK. Las API deben estar disponibles para recuperar información sobre un declarante y para recuperar las tasas de presentación sin necesidad de que el usuario vaya a una solicitud independiente.
24. En la descripción general de las API de EDGAR se enumeran ciertas normas técnicas para las API previstas. ¿Hay alguna consideración que debamos tener en cuenta a la hora de determinar qué estándares técnicos se deben utilizar para las APIs previstas?
Respuesta de XBRL US: En general, somos optimistas sobre los estándares adoptados para la API, sin embargo, nos preocupan las múltiples capas de requisitos para la API de tokens, por ejemplo, los requisitos de vencimiento y de inicio de sesión de 30 días, que serán un desafío, especialmente para los contribuyentes esporádicos.
La Comisión podría considerar la posibilidad de establecer una API adicional que identifique cuándo alguien no ha iniciado sesión en los últimos 30 días. Esto daría a los proveedores la capacidad de verificar la disponibilidad del token y determinar si el token de usuario corre el riesgo de quedar inactivo. El software del proveedor podría llamar a la API y solicitar que el usuario inicie sesión en login.gov para guardar su trabajo. La Comisión tal vez desee también ampliar el plazo de expiración a 90 días en lugar de los 30 propuestos. EDGAR Next también podría tener la posibilidad de enviar un correo electrónico a los usuarios cuando su inicio de sesión esté programado para expirar dentro de un período determinado, por ejemplo, dentro de diez días.
El requisito de 30 días podría tener consecuencias inesperadas, por ejemplo, podría alentar a los registratarios a entregar los códigos a otras organizaciones, como los agentes de archivo, para que puedan evitar tener que iniciar sesión ellos mismos dentro del plazo de 30 días.
Proceso de transición
Pregunta 32: ¿Cuánto tiempo tardarían los declarantes existentes en hacer la transición a EDGAR Next? Según lo planeado, el Período de Inscripción comenzaría un mes después de la adopción de la regla propuesta y los cambios en el formulario. ¿Es esta una cantidad de tiempo suficiente para que los contribuyentes se preparen para la inscripción y, si no es así, por qué? ¿Es suficiente un período de inscripción de seis meses para que los contribuyentes inscriban sus cuentas EDGAR a través de la inscripción manual o masiva y, si no es así, por qué? ¿Deberían los contribuyentes existentes hacer la transición de sus cuentas de EDGAR en un cronograma específico durante el Período de Inscripción (por ejemplo, los contribuyentes grandes deben hacer la transición antes de la fecha X, los contribuyentes medianos antes de la fecha Y, etc.) o, como se contempla, ¿deberíamos permitir que los contribuyentes decidan cuándo hacer la transición a EDGAR Next siempre y cuando lo hagan antes de la fecha de cumplimiento?
Respuesta de XBRL EE. UU.: Recomendamos un período de transición de 12 meses para que los contribuyentes inscriban sus cuentas EDGAR en EDGAR Next. Creemos que seis meses es muy poco tiempo para que los contribuyentes hagan la transición de sus cuentas y, al mismo tiempo, cumplan con las presentaciones activas durante ese período. También recomendamos que el proceso de inscripción no se escalone por tipo de declarante o por cualquier otro medio. La necesidad de hacer un seguimiento de qué proceso de presentación debe utilizarse por declarante, así como el seguimiento de cuándo ese declarante entra en EDGAR Next será un desafío administrativo. Creemos que una sola fecha de transición será mucho menos confusa en general.
33. Planeamos requerir frases de contraseña CIK, CCC y EDGAR para que EDGAR acepte tanto las inscripciones individuales como las masivas. ¿Serían más apropiadas las credenciales alternativas y, en caso afirmativo, qué credenciales deberían utilizarse? En particular, ¿suelen mantener las frases de contraseña los agentes de presentación y, de no ser así, ¿qué tan oneroso sería para los agentes de presentación obtener y mantener las frases de contraseña de sus clientes? En situaciones en las que los declarantes ya no conocen sus frases de contraseña o esas frases de contraseña ya no se reconocen en EDGAR, ¿qué tan oneroso sería para los contribuyentes obtener nuevas frases de contraseña?
Respuesta de XBRL US: Los agentes de presentación y otros proveedores no suelen solicitar ni conservar la contraseña o la frase de contraseña de un registrante. A menos que el contacto de EDGAR que figura en la información de la empresa pueda utilizar el proceso de token de seguridad, el proceso manual de obtención de una nueva frase de contraseña lleva mucho tiempo.
35. ¿Deberíamos permitir la inscripción masiva de varias cuentas de EDGAR, según lo planeado? ¿Hay medidas particulares que la Comisión debería tomar para minimizar los riesgos asociados con la inscripción? Por ejemplo, ¿deberían restablecerse automáticamente los CCC de los contribuyentes inscritos como medida de seguridad después de que se acepte la inscripción? Si el CCC se restablece automáticamente, ¿qué notificación, si la hubiera, debe proporcionarse al contacto EDGAR existente para el declarante?
Respuesta de XBRL US: Estamos de acuerdo con el enfoque propuesto para permitir la inscripción masiva de varias cuentas EDGAR. Recomendamos que el límite de CSV se aumente a 500, desde el límite propuesto de 100.
36. ¿En qué medida la inscripción masiva presentaría cargas logísticas o de otro tipo para los declarantes con múltiples agentes de presentación o administradores de cuentas de terceros no afiliados? Por ejemplo, si el CCC del declarante se restableciera automáticamente después de la inscripción masiva, ¿hasta qué punto esto podría causar confusión si el declarante tuviera varios agentes de presentación y algunos de ellos no se incluyeran inadvertidamente como administradores de cuentas en la inscripción masiva? En lugar de que el CCC se restablezca después de la inscripción, ¿debería restablecerse el CCC en la fecha de cumplimiento de cada CIK inscrito?
Respuesta de XBRL US: Recomendamos no restablecer la CCC, ya que esto sería perjudicial para la mayoría de los declarantes, en particular para los declarantes de la Sección 16.
Solicitud general de comentarios y EDGAR Next proponiendo la versión beta
39. ¿Hay alternativas al tablero que deberíamos considerar? Por ejemplo, ¿existen métodos alternativos que permitan a los declarantes realizar las mismas acciones que harían utilizando el panel de control que sería más fácil de implementar o más fácil de usar? Si es así, ¿cuáles son esas alternativas? Por favor, sea específico.
Respuesta de XBRL US: Se debe poner a disposición un conjunto completo de API de administración de declarantes para que los agentes de presentación y otras entidades que admitan un gran número de registratarios puedan administrarlas de manera eficaz.
Actualmente hay un estimado de 30+ agentes de presentación o bufetes de abogados que manejan 1,000 o más registrantes únicos y seis que manejan más de 5,000 registrantes únicos (2022 hasta la fecha). Esta escala no es manejable con el panel de administración de archivadores y daría lugar a una cantidad abrumadora de correo electrónico e incurriría en una carga de soporte significativa y costos asociados.
40. En relación con los cambios de EDGAR Next, tenemos la intención de proporcionar las API descritas anteriormente para realizar envíos de EDGAR y verificar el estado de envío y el estado operativo de EDGAR. ¿Existen alternativas que logren mejor los objetivos de comunicación segura, eficiente y automatizada de máquina a máquina con EDGAR? En caso afirmativo, sírvase describirlo.
Respuesta de XBRL US: Alentamos a la SEC a desarrollar más API. Las API implementadas como parte de la versión beta son muy sencillas y fáciles de usar, y son una gran mejora con respecto a las API propuestas en la primera ronda de discusiones de EDGAR Next.
Sin embargo, el sistema propuesto de fichas de usuario secretas no es compatible con las prácticas modernas de presentación, en las que las necesidades de presentación de una persona o de un solicitante de registro pueden ser gestionadas por varios agentes de presentación, lo que significa de manera realista que esta ficha se almacenará en varios sistemas y no es más segura que la CCC existente.
Además, el requisito de iniciar sesión en un sitio web de EDGAR, de forma interactiva, cada 30 días significa que muchos propietarios de informes de la Sección 16 serán desactivados continuamente. La propuesta no es clara sobre el proceso necesario para reactivar un token, suponiendo que pueda ser reactivado. En cualquier caso, es probable que la necesidad de reactivar los tokens imponga cargas adicionales a los declarantes.
45. En la actualidad, el EDGAR permite que se presenten determinadas solicitudes en nombre de múltiples declarantes, que son tratados como solicitantes de registro conjunto a los efectos de la presentación. ¿Tendrían dificultades los declarantes para delegar en los solicitantes de registro conjunto o autorizar a las personas a actuar como usuarios o administradores de cuentas tanto para el declarante como para el (los) solicitante (s) de registro conjunto? ¿En qué medida, en su caso, los cambios de EDGAR Next deberían proporcionar una consideración o un tratamiento especial para las presentaciones de EDGAR por parte de los solicitantes de registro conjunto? Por ejemplo, ¿debería el tablero permitir que los declarantes designen a otros declarantes como «co-registrantes» de manera similar a como los declarantes delegarían a otros declarantes como entidades delegadas, excepto que la autoridad de presentación solo existiría con respecto a las presentaciones de los solicitantes de registro conjunto (por ejemplo, el co-registrante no podría presentar una presentación únicamente en nombre del declarante)? En caso afirmativo, ¿en qué medida los solicitantes de registro conjunto deben recibir un trato diferente al de las entidades delegadas (por ejemplo, en lo que respecta a los grupos de usuarios, los administradores delegados, etc.)? Alternativamente, ¿debería un usuario o administrador de la cuenta de un declarante poder presentar una presentación conjunta de un solicitante de registro conjunto en nombre del solicitante de registro conjunto utilizando el CIK y el CCC del cosolicitante de registro (como es el caso actualmente), sin ser un usuario o administrador de la cuenta del solicitante de registro conjunto? ¿Por qué sí o por qué no? Tenga en cuenta que, a los efectos de la Propuesta Beta de EDGAR Next, un declarante podrá presentar una presentación de registro conjunto ingresando el CCC y el CIK del (los) solicitante (s) de registro conjunto, como es el caso actualmente.
Respuesta de XBRL US: Alentamos a la Comisión a continuar con la implementación beta existente, que solo aplica los requisitos de Declarante y Token de usuario para el registrante principal, en la fase final de regla/implementación.
57. ¿Está de acuerdo con los costos estimados asociados con los cambios de EDGAR Next? Si no es así, ¿por qué? Por favor, proporcione su opinión sobre la carga de cumplir con los cambios de EDGAR Next en relación con nuestras estimaciones. En particular, ¿cambiarían los declarantes y los agentes de presentación a utilizar las API opcionales contempladas como parte de EDGAR Next? Si no es así, ¿por qué?
Respuesta de XBRL US: El impacto económico descrito en la norma propuesta no incluye los costos adicionales de apoyo no relacionados con el desarrollo. Se estima que los agentes de presentación y los bufetes de abogados son responsables de más del 90% de las presentaciones de EDGAR. Es probable que los costos adicionales de apoyo se transfieran a los inscritos. Por ejemplo, es posible que muchos agentes de archivo necesiten contratar personal adicional para administrar el panel de archivo, los tokens de API y el soporte para sus clientes.
El tiempo estimado de desarrollo de 96-120 horas parece extremadamente optimista.
Según la experiencia de implementación de la API por parte de uno de nuestros miembros proveedores, la implementación básica de la API tardó al menos el doble de tiempo. La integración completa de la API en la aplicación de presentación preexistente llevará al menos el mismo tiempo. También hay un estimado de 8 horas por semana para realizar un seguimiento de los cambios en la versión beta hasta marzo de 2024. Además, los cambios para almacenar y administrar de forma segura los tokens de usuario y archivador podrían agregar fácilmente 240 horas de desarrollador.
Además, la respuesta de la API de estado no abarca completamente la información que se proporciona en la representación HTML actual. Este cambio requerirá tiempo y recursos adicionales, que actualmente no se pueden cuantificar, para intentar replicar la información que se proporcionó anteriormente.
Tal como está la regla propuesta, los declarantes y los agentes de archivo deberán usar las API proporcionadas como autenticación login.gov para acceder al servicio EDGAR basado en la web, lo cual no es técnicamente factible. Esto subraya la necesidad de API que repliquen completamente la funcionalidad del servicio actual basado en web.
60. ¿Exigiría EDGAR Next a los declarantes existentes con autoridad delegada que presenten una declaración en nombre de una persona o entidad vinculada que cambien sustancialmente la forma en que operan? Si es así, ¿de qué manera? ¿Cuál sería el costo asociado con tal cambio? Por ejemplo, muchas empresas pueden presentar una solicitud en nombre de sus directores y funcionarios de la sección 16, y algunas empresas de inversión también pueden presentar solicitudes en nombre de otros fondos dentro de su familia de fondos.
Respuesta de XBRL US: Como se señaló en respuestas anteriores a las preguntas de la propuesta, no creemos que la propuesta de norma aborde adecuadamente las necesidades de los declarantes de la Sección 16 y que los declarantes individuales realizarán su propia gestión del código. Para estos declarantes, la regla no aborda específicamente cómo pueden manejar esto. Muchos forman parte de los consejos de administración de varias empresas, algunos hasta 20, y tendrán que configurar o designar a cada persona como administrador de cuentas. La Comisión debe abordar cómo puede haber un método más fácil para delegar el permiso para que alguien presente en su nombre. En las pruebas BETA no estaba claro que un declarante individual pudiera tener un solo administrador, aunque la regla aclara que otras empresas deben tener al menos dos.
Además, muchos declarantes gestionan sus propias credenciales de la SEC. Todos ellos se verán afectados por este cambio si se ven obligados a delegar.
61. Los posibles declarantes podrían designar como administradores de cuentas a (i) personas empleadas en el declarante o a una filial del declarante (en el caso de los solicitantes de empresas) o a ellos mismos (en el caso de los solicitantes individuales), así como (ii) a cualquier otra persona, siempre que el declarante presentara un poder notarial que autorizara a esa otra persona a ser su administrador de cuenta. ¿Es probable que los declarantes designen a personas distintas de ellos mismos o de sus empleados o empleados de sus afiliados? ¿Cuáles serían los costos asociados con esta determinación?
Respuesta de XBRL US: El nuevo requisito de la administración puede incentivar a los registratarios a avanzar hacia el modelo de delegación y aumentar la dependencia de servicios que de otro modo no serían necesarios en la actualidad. Esto podría poner a los proveedores más pequeños en desventaja dada la carga de apoyo adicional y, en cualquier caso, los costos más altos serán asumidos por los declarantes en última instancia.
Gracias de nuevo por la oportunidad de aportar nuestra opinión a la propuesta de norma sobre la aplicación de EDGAR Next. Estaremos encantados de responder a cualquier pregunta o de dar más detalles sobre nuestras respuestas a esta propuesta de norma.
Sinceramente
XBRL US RMWG
Sinceramente
Grupo de Trabajo de Modernización Regulatoria de XBRL US
(Nombres de los miembros y organizaciones: https://xbrl.us/xbrl-reference/rmwg/)
Publicado originalmente: https://www.xbrl.org/news/xbrl-us-working-group-provides-commentary-on-secs-edgar-next-proposal/