Acerca de Organizations

Antes de empezar

Necesitas una cuenta de Kraken empresarial verificada mediante KYB para crear una Organization. Las cuentas de Kraken personales no son válidas.

Solo el poseedor de la cuenta que completó la verificación empresarial puede crear una Organization. Tras la creación, esta persona pasa a ser el Organization Owner.

No puedes deshacer la creación de una Organization por ti mismo. Una vez creada una Organization, revertirla requiere asistencia de soporte.

Nota: Organizations se encuentra actualmente en fase Beta. Algunas funciones pueden tener limitaciones. Consulta Limitaciones de la Beta para más información.

Organizations de un vistazo

Organizations permite a los clientes institucionales gestionar el acceso del equipo y exigir aprobaciones para acciones sensibles en cuentas compartidas.

  • Invita a miembros del equipo a tu Organization
  • Asigna permisos por flujo de trabajo y cuenta
  • Exige aprobaciones para acciones sensibles como retiros, cambios de dirección y actualizaciones de permisos
  • Aplica controles de seguridad compartidos, como la verificación en dos pasos (2FA) y la expiración de sesión por inactividad
  • Implanta la gobernanza de forma gradual: empieza rápido y refuerza después

Roles principales

Organization Owner – el poseedor de la cuenta que creó la Organization. El Owner comienza con permisos administrativos completos y es el responsable de configurar el acceso y la gobernanza del equipo. No existe el rol de co-owner.

Member – una persona invitada a la Organization con permisos específicos. Los Members inician sesión con sus propias credenciales de Kraken y deben cumplir la política de Verificación en dos pasos para el inicio de sesión de la Organization.

Service User – un operador exclusivo de API creado dentro de la Organization. Los Service Users se autentican con credenciales de API y pueden iniciar solicitudes, pero no pueden aprobarlas ni iniciar sesión en la interfaz. Consulta Service Users para más información.

Términos clave

Organization – El contenedor de nivel superior que agrupa a los miembros, cuentas y gobernanza en una única estructura.

Account – Una unidad con balances segregados para trading y depósito y retiro. Los permisos se conceden por cuenta; el acceso a una cuenta no se extiende a las demás. El trading multiacuenta está previsto para una versión futura.

Permission – Una concesión que define qué puede hacer un miembro o Service User. Los permisos son acumulativos: los usuarios parten sin ningún acceso y cada permiso debe concederse de forma individual. Consulta Permissions and workflows para la referencia completa.

Workflow – Un conjunto de operaciones relacionadas que comparten el mismo modelo de permisos y configuración de política. Organizations tiene cuatro workflows: Initiate Withdrawal, Manage Addresses, Manage Access y Manage Policies.

Operation – Una acción específica dentro de un workflow. Por ejemplo, "Create a crypto withdrawal" es una operación del workflow Initiate Withdrawal.

Policy – La configuración de gobernanza de un workflow. Una política define cuántas aprobaciones se requieren y si un subconjunto de usuarios puede completar las acciones de forma inmediata. Consulta Policies, approvals, and governance para más información.

Request – Una unidad de trabajo que se crea cuando un miembro o Service User inicia una acción en un workflow gobernado. Las solicitudes se completan de forma inmediata (si la política lo permite) o se colocan en la cola de aprobación para su revisión.

Execute – Un permiso que permite a un miembro completar acciones sin esperar aprobación, siempre que la política del workflow lo permita. Cuando "Always require approval" está activado, Execute no tiene ningún efecto.

Policy lock – Un control de gobernanza que impide que una sola persona modifique la política de un workflow. Los cambios futuros requieren una aprobación independiente y dependen de que siga habiendo aprobadores disponibles.

Separation of duties – La regla que impide que un miembro apruebe su propia solicitud. Aplicado por el sistema y no anulable.

Reglas clave y controles de seguridad

  • Los miembros no pueden aprobar sus propias solicitudes. Aplicado por el sistema y no anulable.
  • Los permisos son acumulativos. Los miembros parten sin acceso y hay que concederles cada permiso de forma individual.
  • Que una acción se complete de inmediato o requiera aprobación depende tanto de los permisos del miembro como de la política del workflow. Consulta Permissions and workflows.
  • Las políticas bloqueadas no se pueden modificar sin una aprobación independiente, ni siquiera por el propietario.
  • Se requiere la Verificación en dos pasos para el inicio de sesión en la organización. La política se establece en el momento de la creación y se aplica a todos los miembros actuales y futuros.
  • Las sesiones inactivas caducan y requieren nueva autenticación.

Resumen de las limitaciones de la Beta

Organizations se encuentra actualmente en fase Beta. Limitaciones principales:

  • Solo está disponible el modo de cuenta única; el trading con varias cuentas aún no es compatible
  • Algunas operaciones de la plataforma son exclusivas del propietario (Futures, OTC, Convert, Custody)
  • Los registros de auditoría para clientes aún no están disponibles
  • Los roles personalizados no se pueden guardar ni reutilizar
  • La confirmación por email de los cambios de dirección inmediatos se envía al propietario, no a quien creó la solicitud
  • Algunas operaciones pueden diferir entre la interfaz y la API durante la Beta

Consulta Limitaciones de la Beta para ver la lista completa.

Qué puedes gestionar

Organizations agrupa las acciones en cuatro áreas de workflow. Cada workflow tiene sus propios permisos y configuraciones de política.

Flujo de trabajo

Qué controla

Iniciar retiro

Quién puede solicitar, aprobar y completar retiros de dinero fiduciario y criptomonedas

Manage Addresses

Quién puede añadir o eliminar destinos de retiro en la lista blanca

Manage Access

Quién puede invitar a miembros, gestionar Service Users y modificar permisos

Manage Policies

Quién puede modificar las reglas de aprobación y bloquear la configuración de gobernanza

Consulta Permissions and workflows para la referencia completa.

Introducción

¿Listo para configurar tu Organization? Consulta Crear una Organization para ver el proceso completo de creación y los primeros pasos, incluidos cómo invitar a miembros, asignar permisos, configurar políticas de aprobación y bloquear la gobernanza cuando estés listo.

Preguntas frecuentes

No. El Organization Owner es el poseedor de la cuenta que creó la Organization. La titularidad no puede transferirse mediante autoservicio.

No. La creación de una Organization no es reversible mediante autoservicio. Contacta con soporte si necesitas hablar sobre opciones de migración.

El Owner conserva acceso completo a la cuenta. No se elimina ninguna funcionalidad existente. Los miembros solo obtienen acceso a las acciones para las que se les han concedido permisos de forma explícita.

Actualmente, cada miembro pertenece a una única Organization. En una versión futura, Organizations admitirá varias entidades empresariales bajo una misma estructura, lo que permitirá a los miembros realizar operaciones entre entidades dentro de la misma Organization.

Los Service Users pueden iniciar solicitudes de retiro mediante la API. Cuando una política de Organization rige el flujo de trabajo Initiate Withdrawal, los miembros humanos deben aprobar la solicitud antes de que surta efecto. Los Service Users también pueden operar y gestionar productos Earn según los permisos de su clave API. Consulta Service Users.

¿Necesitas más ayuda?