Recompensas y pagos

Por qué es importante

Las recompensas y los pagos están incluidos en todas las suscripciones activas de Kit. El flujo incluye el pipeline completo de desembolsos, el libro mayor inmutable y la gestión de documentos fiscales que se describen en esta página.

Gestionar bien los pagos es tanto una cuestión de retención de investigadores como una obligación de cumplimiento normativo. Las transferencias manuales por PayPal sin recopilar formularios W-8BEN (no residentes en EE.UU.) o W-9 (residentes en EE.UU.) generan una exposición directa ante el IRS para tu empresa. Cada pago a un investigador es un evento gravable declarable, y la ausencia de documentación fiscal traslada la responsabilidad a ti. El pipeline de desembolsos de Kit resuelve esto condicionando los pagos a un checklist de preparación configurable que incluye la verificación de documentos fiscales.

El libro mayor inmutable es la principal pieza de pruebas SOC 2 para los controles financieros de tu programa de divulgación de vulnerabilidades. Cada aprobación de recompensa, cada desembolso y cada acción sobre documentos fiscales se registra con actor, marca de tiempo y monto. Los auditores pueden verificar la cadena de custodia completa, desde la resolución del informe hasta la confirmación del pago, en una sola exportación.

Matriz de recompensas

La matriz de recompensas asigna rangos en dólares a los niveles de severidad CVSS. Configúrala en VDP > Program Settings > Bounty Matrix. Cuando un miembro del equipo puntúa un informe con una evaluación CVSS, el rango de recompensa sugerido se extrae automáticamente de la matriz y se precarga en el formulario de aprobación.

Los rangos de recompensa se muestran en tu página pública de política de divulgación para que los investigadores sepan qué esperar antes de enviar un informe. Esta transparencia reduce disputas y establece expectativas claras.

Para programas de solo reconocimiento, deja todos los niveles en $0. Los investigadores verán «recognition only» en la página de la política en lugar de montos en dólares.

Consulta Cómo configurar tu programa para más detalles sobre la configuración de la matriz.

Dos caminos para llegar a un monto

Hay dos caminos hacia una recompensa aprobada, y ambos terminan en la misma acción irreversible.

Camino	Cómo funciona	Úsalo cuando
Aprobación directa	Un administrador escribe un monto y lo aprueba. Un solo paso. Se describe más abajo.	La cifra es obvia: un informe de severidad baja en la parte inferior de su banda de la matriz, un hallazgo casi duplicado, cualquier cosa que nadie discutiría.
Proponer y luego aprobar	Cualquier miembro pone un monto sobre la mesa con una justificación. Los compañeros se muestran de acuerdo u objetan con importes alternativos. Después, un administrador aprueba.	La cifra es discutida, inusualmente alta o sienta un precedente que te recordarán en el siguiente informe.

Las propuestas son consultivas e invisibles para el investigador: nada de una propuesta notifica al investigador, escribe en el libro mayor ni mueve dinero. Tampoco condicionan nada: un administrador puede aprobar directamente en cualquier momento, haya o no una propuesta abierta. Consulta Propuestas de recompensa y votación del equipo.

Aprobar una recompensa

Los administradores pueden aprobar una recompensa en cualquier momento antes de que el informe llegue al estado Paid. Como buena práctica, espera a que el informe esté validado, idealmente resuelto, para que el monto refleje una vulnerabilidad confirmada y evaluada.

Para aprobar una recompensa:

1. Abre la página de detalle del informe
2. Haz clic en Approve Bounty
3. Completa el formulario de aprobación

Campo	Requerido	Descripción
Amount	Sí	Monto de la recompensa, precargado desde la matriz de recompensas según el nivel de severidad CVSS del informe.
Currency	Sí	Por defecto USD. Debe coincidir con la moneda configurada en tu programa.
Notes	No	Notas internas visibles solo para tu equipo. Cifradas en reposo.

La aprobación requiere un envío explícito: ningún monto se compromete hasta que guardes el formulario. Al aprobar:

• Se agrega una entrada bounty_approved al libro mayor inmutable
• Se notifica al investigador a través de la plantilla de correo Recompensa aprobada
• Cualquier propuesta de recompensa abierta en el informe se cierra como sustituida, con sus votos conservados como registro

Ese último punto merece atención si tu equipo usa propuestas: aprobar directamente mientras hay una propuesta abierta paga el monto que escribiste, no el que el equipo estaba discutiendo, y pone fin a la deliberación. Cuando quieras el monto propuesto, aprueba desde la pestaña Recompensa del informe.

Revocar una recompensa

Desestimar un informe que tiene una recompensa aprobada la revoca automáticamente. El modal de desestimación te advierte con el monto, el aprobador y la fecha de aprobación, y el botón de envío cambia a Dismiss & revoke $X bounty. Al revocar:

• Se agrega una entrada bounty_revoked al libro mayor inmutable como débito; los totales de aprobado y pendiente del libro mayor la restan. Los metadatos de la entrada registran el motivo de la desestimación, el aprobador original con su fecha de aprobación y el estado del desembolso en ese momento.
• El email de desestimación al investigador indica que la recompensa previamente aprobada ha sido retirada y no se pagará; el flujo de apelación habitual es el recurso disponible. Su portal muestra una nota de «retirada» en lugar de la tarjeta de recompensa.
• El karma otorgado por la recompensa se revierte con un evento de karma “Bounty Revoked”.

Aplican dos salvaguardas:

• Una recompensa cuyo desembolso está Completed nunca se puede revocar.
• Un pago en curso (desembolso Pending o Processing) bloquea la desestimación. Marca primero el desembolso como fallido, o deja que se complete. Solo un desembolso en Processing puede marcarse como fallido; Pending es un estado transitorio de menos de un segundo (consulta Estados de desembolso), no un estado sobre el que puedas actuar.

Deshacer una desestimación no restablece la recompensa. Cuando el informe se valide de nuevo, aprueba una nueva recompensa manualmente; la interfaz muestra un recordatorio.

Pipeline de desembolsos

Navega a VDP > Disbursements para gestionar los pagos. La cola se abre en un conjunto de pestañas para que siempre veas la parte del trabajo que te interesa: Ready, Blocked, With Finance, Paid, Failed y All. Por defecto aterrizas en la pestaña Ready.

En la parte superior hay cuatro tarjetas de resumen:

• Ready: informes con una recompensa aprobada y sin desembolso todavía, en los que el checklist de preparación está cumplido y el dinero ya puede moverse.
• Blocked: informes con una recompensa aprobada y sin desembolso todavía, en los que el checklist de preparación aún no está cumplido.
• In Progress: pagos ya entregados a finanzas y a la espera de confirmación.
• Oldest Waiting: la recompensa aprobada sin pagar más antigua que sigue en curso. Muestra cuántos días lleva esperando, el investigador y el monto, y enlaza directamente a la pestaña en la que aparece esa fila para que puedas actuar sobre ella.

El dinero en distintas monedas nunca se suma. Cada tarjeta muestra los importes por moneda, de modo que un programa que paga en USD y EUR ve ambos totales uno al lado del otro en lugar de una cifra combinada sin sentido.

Las pestañas Ready y Blocked son las dos mitades del mismo conjunto (informes con una recompensa aprobada pero sin desembolso todavía), separadas según si el checklist de preparación está cumplido.

Checklist de preparación

Antes de que un desembolso pueda continuar, el investigador debe cumplir un checklist de preparación. Los tres elementos son configurables en la configuración de pagos de tu programa:

• Información de pago enviada: el investigador ha ingresado sus datos de pago (banco, PayPal u otro método) a través de el portal del investigador
• Acuerdo aceptado: el investigador ha aceptado el acuerdo de participación de tu programa (si tu programa lo requiere)
• Documento fiscal verificado: el W-8BEN o W-9 del investigador se ha subido y tu equipo lo ha verificado (si tu programa requiere documentos fiscales)

Los elementos que no están habilitados en la configuración de tu programa se marcan automáticamente como satisfechos.

El checklist también depende del estado del informe, controlado por Require Verified Fix Before Payout en VDP > Program Settings > Payouts:

• Activado (por defecto): la recompensa solo se puede desembolsar después de que tu equipo marque como verificada la corrección del informe. Nunca pagas por un fallo sin resolver, pero los investigadores pueden tener que esperar a que la corrección se publique.
• Desactivado (pago al validar): el pago se desbloquea en cuanto el informe llega a Validated, la norma del sector en plataformas como HackerOne y Bugcrowd. A los investigadores se les paga más rápido, y el pago se desacopla del cierre del informe: el informe permanece abierto después de mover el dinero y se cierra como Paid automáticamente una vez que se resuelve (o se verifica la corrección). Los informes pagados nunca se pueden desestimar, y la verificación de la corrección pasa a ser un paso opcional de QA: regístrala antes de que el informe se resuelva, o no quedará registrada.

El tablero de seguimiento

La pestaña Blocked es un tablero de seguimiento: en lugar de una lista plana de pagos atascados, agrupa los pagos bloqueados por investigador, de modo que le das un toque a una persona una sola vez en vez de perseguir a la misma persona a lo largo de varias filas. Los envíos anónimos, que no tienen ningún investigador registrado, forman su propio grupo sin investigador.

Cada grupo muestra:

• El investigador (o «anónimo» para el grupo sin investigador)
• Cuántos de sus pagos están bloqueados
• El total adeudado, por moneda
• Qué bloqueos aplican, en forma de chips: Payout info, Tax document y Agreement
• Cuántos días lleva esperando el pago más antiguo del grupo

Los grupos se ordenan primero por toque pendiente (los investigadores a los que puedes escribir ahora mismo suben arriba) y, dentro de eso, primero los que llevan más tiempo esperando.

Cada grupo también indica cuánto liberaría un toque, con una cifra de «desbloquea N pagos / X USD». Cuenta solo los informes en los que cada elemento requerido pendiente es algo que el propio investigador puede resolver (información de pago, documento fiscal, acuerdo). Un informe que todavía espera la verificación de la corrección (un paso que corresponde a tu equipo) no se cuenta, porque escribir al investigador no lo liberará.

Dar un toque a un investigador

Desde la pestaña Blocked, haz clic en Nudge en un grupo de investigador para enviarle un recordatorio por correo. El recordatorio requiere el permiso de pago (disburse).

Un único correo por investigador cubre todos sus puntos pendientes actuales de una vez (información de pago, documento fiscal y cada acuerdo por informe) en lugar de enviar un correo distinto por cada bloqueo. El investigador recibe una única lista de tareas completa.

Cada bloqueo del correo es un enlace mágico directo. Un solo clic autentica al investigador y lo lleva a la página exacta que resuelve ese punto: el formulario de información de pago, la subida del documento fiscal o el acuerdo del informe concreto. Como el token no tiene estado, el enlace mágico de inicio de sesión que ya tiene el investigador sigue siendo válido: un toque nunca lo invalida.

Los toques están limitados por un periodo de enfriamiento por (cuenta, investigador) de 3 días. Si ya le diste un toque a ese investigador dentro de la ventana, el botón indica que está en enfriamiento en lugar de reenviarlo. El enfriamiento se aplica por inquilino: el toque de un cliente nunca afecta al de otro, ni siquiera para un investigador que envía informes a varios programas.

Nudge solo aparece cuando el investigador puede desbloquear algo. Los puntos pendientes a nivel de informe (aprobación de la recompensa, validación y verificación de la corrección) son tarea de tu equipo y nunca se notifican con un toque; un toque se ofrece solo para los elementos que el investigador puede resolver.

Procesar un pago

Kit no ejecuta transferencias bancarias ni llamadas a APIs de pago. Tu equipo se encarga del movimiento real de dinero fuera de Kit (transferencia bancaria, PayPal, criptomonedas, etc.). Kit hace seguimiento del ciclo de vida:

1. Cuando todos los elementos de preparación están satisfechos, haz clic en Initiate para mover el desembolso a Processing
2. Ejecuta la transferencia a través de tu proveedor de pagos
3. Vuelve a Kit y haz clic en Mark as Paid: ingresa la referencia de la transacción (por ejemplo, el ID de transacción de PayPal o el número de confirmación de la transferencia)
4. El desembolso pasa a Completed y el informe pasa a Paid (en los programas con pago al validar, un informe pagado antes de resolverse permanece abierto y se cierra como Paid automáticamente en cuanto llega a ese punto)

Confirmación del equipo de finanzas

La persona que programa el pago suele estar en finanzas, no en seguridad. Kit ofrece dos vías claramente delimitadas:

• El rol Finanzas ofrece una cola con inicio de sesión para desembolsos a investigadores y revisión de formularios W-8/W-9. Permite iniciar, completar, reintentar o registrar el fallo de un pago, pero no leer informes, aprobar recompensas, cambiar la configuración de pagos ni usar las exportaciones generales.
• Una bandeja como [email protected] sirve para quienes deben actuar desde un enlace seguro sin una cuenta de Kit.

Seguridad sigue decidiendo si corresponde una recompensa y su importe. Finanzas ejecuta y registra el pago aprobado.

Actívalo configurando Finance Email en VDP > Program Settings > Payouts. Deja el campo en blanco para seguir registrando los pagos manualmente en Kit.

Con un correo de finanzas configurado, al hacer clic en Initiate también se envía una solicitud de pago a esa dirección con:

• El destinatario (investigador), el monto y el método de pago: las direcciones de PayPal se muestran completas; los números de cuenta bancaria se enmascaran salvo los últimos cuatro dígitos, con los datos completos disponibles solo tras el enlace de confirmación
• La referencia del desembolso que se debe incluir en el concepto del pago, para que la conciliación funcione en ambos sentidos
• La procedencia de la aprobación: quién aprobó la recompensa y cuándo, y quién inició el pago
• Un enlace seguro, válido durante 90 días, con dos acciones posibles: confirmar el pago o notificar que falló

La persona de finanzas abre el enlace, ve los datos completos del pago, lo realiza a través de tu proveedor de pagos y luego ingresa la referencia de la transacción y su nombre para confirmar. Confirmar completa el desembolso exactamente igual que un Mark as Paid interno: se escribe la entrada del libro mayor, el informe pasa a Paid, se notifica al investigador automáticamente y tu equipo recibe la notificación de finalización de pago habitual, que señala como responsable de marcarlo como pagado a la persona de finanzas que lo confirmó. La confirmación registra quién confirmó (nombre y correo), cuándo y desde dónde (dirección IP), visible en la fila del desembolso como Confirmado por finanzas.

Si el pago no sale adelante, la misma página ofrece un enlace Notificar un pago fallido bajo el formulario de confirmación. Eso registra el fallo con la misma procedencia (quién lo notificó, cuándo y desde dónde) y la fila del desembolso lo muestra como Pago fallido · Notificado por …. Consulta Cuando falla un pago.

Algunos detalles que conviene conocer:

• Las respuestas llegan a una persona. El reply-to del correo es el miembro del equipo que inició el pago, así que las preguntas de finanzas llegan a alguien que tiene contexto.
• Reenvía cuando quieras. La fila del desembolso muestra cuándo y dónde se envió la solicitud, con un botón de reenvío que emite un enlace nuevo.
• El flujo interno sigue disponible. Si finanzas responde «hecho, ref. #123» por correo en lugar de hacer clic, tu equipo todavía puede marcar el desembolso como pagado manualmente; el enlace mostrará entonces un recibo de «ya registrado».
• El enlace muere con el desembolso. Una vez completado o fallido, el enlace ya no puede confirmar ni notificar nada; solo muestra el estado actual. Un fallo notificado a través del enlace muestra a finanzas su propio recibo: quién lo notificó, la fecha, el motivo y una línea que le pide no reintentar el pago porque llegará una solicitud nueva.
• Una confirmación de finanzas ya cuenta como una segunda persona. Como el pago se confirmó desde fuera de tu equipo en Kit, el aprobador siempre recibe la notificación de confirmación y el aviso de segunda revisión que se describe más abajo nunca aplica: alguien distinto del aprobador ya dio el visto bueno al pago.
• Las cancelaciones se anuncian cuando las anula tu equipo. Si se envió una solicitud de pago y tu equipo marca después el desembolso como fallido desde Kit, finanzas recibe, desde el mismo remitente con tu marca, un aviso «Pago cancelado: no pagar», para que nadie transfiera dinero por un pago que has retirado. Cuando es finanzas quien notifica el fallo a través del enlace, no se envía ningún aviso. Ellos son quienes nos lo dijeron, y su recibo ya explica qué pasará a continuación.

Cuando falla un pago

Kit nunca mueve dinero, así que nunca se entera de que una transferencia falló. Alguien tiene que decirlo, y marcar un pago como fallido es exactamente esa declaración. Es un apunte contable: no se mueven fondos, no se reembolsa nada y la recompensa aprobada queda intacta; el importe íntegro sigue reservado para el investigador.

Pueden registrarlo dos personas. Tu equipo usa Marcar fallido en la fila del desembolso, que requiere el permiso de pago (disburse). Finanzas usa el enlace Notificar un pago fallido de la página de confirmación, de modo que quien tiene delante el rechazo del banco puede registrarlo sin pasarlo antes por tu equipo.

Ambas vías hacen la misma pregunta con las mismas cinco respuestas:

Motivo	Qué hace de cara al investigador
El destinatario no puede aceptar pagos en este momento	Envía un correo al investigador pidiéndole información de pago que funcione
Los datos de la cuenta no correspondían a una cuenta real	Envía un correo al investigador pidiéndole información de pago que funcione
El pago salió, pero nos fue devuelto	Envía un correo al investigador pidiéndole información de pago que funcione
Otra cosa	No contacta a nadie; solo triaje interno. Requiere una nota, porque esa nota será lo único que tenga tu equipo para orientarse
Este método de pago no sirve para este destinatario	Envía un correo al investigador pidiéndole información de pago que funcione

Todos los motivos salvo Otra cosa envían un correo al investigador. El correo nombra el motivo en términos que entiende, reitera que el importe íntegro sigue reservado y lleva un enlace mágico que lo deja directamente en su página de pago. Nunca cita la nota: lo que hayan escrito finanzas o tu equipo (un mensaje de error del portal del banco o una referencia interna) se queda dentro de tu equipo.

Los envíos anónimos no tienen ningún investigador registrado, así que no es posible enviar ningún correo, elijas el motivo que elijas.

La fila pasa a la pestaña Failed de la cola. La cronología del informe registra el fallo solo con el código del motivo; la nota nunca se publica en la cronología. El libro mayor recibe una entrada disbursement_failed que también lleva únicamente ese código.

Interpretar una fila fallida

Una fila fallida debe responder a una sola pregunta: ¿reintento o sigo esperando al investigador? Reintentar contra la cuenta que acaba de rechazar el pago solo producirá otro rechazo, así que la fila afirma únicamente lo que Kit puede demostrar y nunca lo que supone.

Al enviar un pago, Kit registra el método utilizado y la cuenta de destino. Tras el rechazo, los compara con los datos actuales del investigador y muestra exactamente uno de estos mensajes:

La fila indica	Qué significa	Qué hacer
Datos cambiados hace 2 días · PayPal m•••@gmail.com → PayPal e•••@live.com	Los datos guardados son distintos de los que rechazaron el pago	Reintentar
Guardados de nuevo hace 2 días: son los mismos datos que rechazaron el pago	El investigador abrió la página y guardó sin cambiar nada	No reintentes. Ponte en contacto: probablemente no entendió qué debía corregir
Los mismos datos que rechazaron el pago: es probable que vuelva a fallar	No se ha tocado nada desde el rechazo	Espera o insiste al investigador
El investigador guardó datos hace 3 días, pero no se puede confirmar que sean distintos	El pago falló antes de que Kit empezara a registrar esta comparación. Sí sabemos que guardó algo	Es razonable reintentar, pero es una conjetura, no una confirmación

Los identificadores de cuenta siempre aparecen enmascarados. Si un pago no tiene un destino registrado ni señales de que el investigador haya tocado sus datos, no aparece ninguna de estas líneas: Kit guarda silencio en vez de afirmar algo que no puede respaldar.

El botón Reintentar sigue el mismo criterio. Es la acción principal de la fila solo en los dos estados donde hay datos recientes; pasa a un estilo secundario y discreto en los dos donde reenviaría el pago a la misma cuenta fallida. Ese estilo comunica la preparación, no es decorativo.

Se conserva cada intento. Reintentar ya no borra el pago rechazado. Cada intento anterior permanece en la fila como una línea propia (Intento 1 rechazado hace 12 días · El destinatario no puede aceptar pagos), de modo que puedes ver si es la tercera vez que la cuenta rechaza el dinero. El historial se muestra en pantallas anchas; en las estrechas se oculta para mantener legibles las filas.

«Se ha contactado al investigador» es un registro, no una suposición. La línea Se ha contactado al investigador · hace 3 días solo aparece cuando el correo se ha entregado y muestra la hora de envío. Si una fila recién fallida aún no la muestra, el correo sigue en tránsito.

El callejón sin salida de «Otra cosa»

Otra cosa no contacta a nadie, a propósito. Es la vía de escape del triaje interno: utilízala cuando solo marcas el pago como fallido para desbloquear una desestimación o cuando la causa es interna y los datos del investigador son correctos.

Ese silencio antes era invisible en la cola y dejaba pagos reales abandonados durante semanas: la fila parecía cualquier otro fallo y nadie se daba cuenta de que nunca se había avisado al investigador. Ahora las filas fallidas como Otra cosa lo explican (No se ha contactado: «Otra cosa» nunca llega al investigador) e incluyen el botón Pedir datos nuevos como acción principal.

Al pulsarlo se envía la misma solicitud de datos que los demás motivos envían automáticamente y la fila registra la hora del envío. El correo nunca cita tu nota ni nombra el motivo: solo dice que el pago no pudo completarse y pide datos que funcionen. Después, el botón desaparece y da paso a la línea Se ha contactado al investigador.

Cuando el programa no ofrece otra opción

En ocasiones el investigador no puede arreglar los datos porque tu programa solo admite un método y ese método no funciona para su país o cuenta. Si un pago lleva 14 días fallido, el investigador ha recibido la solicitud de datos y el programa solo tiene activado ese método, el problema ya no está en la fila: está en la configuración del programa.

Cuando ocurre, Kit envía un único correo a los administradores de CSIRT con el nombre del investigador, el importe, el informe y cuánto tiempo lleva esperando la recompensa. La fila fallida muestra la misma nota con un enlace a la configuración de pagos.

Qué hacer: activa un segundo método de pago en el programa y pide al investigador que lo elija antes de reintentar. Si ofrecer una única vía es una decisión expresa, no tienes que hacer nada. El aviso se limita a uno por programa cada 90 días para no insistir en cada rechazo.

Volver a poner el pago en cola

El reintento es manual y exclusivo del equipo: el investigador no puede activarlo. Emite una nueva solicitud de pago con una nueva referencia y un nuevo enlace, y el enlace de confirmación anterior deja de servir. Esto matiza la referencia descrita más arriba: una referencia identifica un intento, no la recompensa, así que una recompensa pagada al segundo intento se concilia contra la segunda referencia.

El intento sustituido no se elimina. Sigue visible en la fila y en el libro mayor como parte del registro de todo lo que ya se ha intentado.

stateDiagram-v2
    state "Processing" as Processing
    state "Failed" as Failed
    state "Researcher updates payout info" as Updated
    state "Processing (new disbursement)" as Retried

    [*] --> Processing: Initiate
    Processing --> Failed: Marked failed by your team or by finance
    Failed --> Updated: Researcher emailed — every reason but "Something else"
    Updated --> Retried: Retry
    Retried --> [*]: Mark paid

    note right of Retried
      Retry does not revive the failed payout.
      It starts a fresh one, so the old
      reference and link are dead — but the
      bounced attempt stays on the row.
    end note

Notificaciones de finalización de pago

Cuando un desembolso se marca como pagado, Kit avisa a tu equipo. Así se cierra el círculo entre autorizar el dinero y moverlo: quien aprobó la recompensa se entera de que se ha pagado sin tener que vigilar la cola.

Hay tres niveles, y son distintos a propósito. Dos son informativos. El tercero no.

Nivel	Quién lo recibe	Cuándo se envía	¿Se puede desactivar?
Confirmación	El miembro del equipo que aprobó la recompensa	En cada pago completado, salvo que sea esa misma persona quien lo marque como pagado	Sí
Segunda revisión	Los administradores del programa, salvo quien lo marcó como pagado	Una sola persona aprobó, ajustó y pagó la misma recompensa, y el monto creció de forma significativa	Sí
Descuadre del libro mayor	El aprobador y todos los administradores del programa, salvo quien lo marcó como pagado	La recompensa registrada en el informe y su historial en el libro mayor ya no coinciden	No

La confirmación es el caso normal, y el que verás casi siempre. El aprobador recibe una nota breve: quién marcó la recompensa como pagada, por cuánto, cuándo y la referencia de la transacción si se introdujo alguna. Si la recompensa se ajustó por el camino, la nota indica la aprobación original y, por separado, el monto al que se ajustó y quién lo hizo, para que las cifras cuadren de un vistazo. Cuando la misma persona aprobó y completó el pago, no se envía nada: nadie necesita que le cuenten lo que acaba de hacer. Si el aprobador ya no es miembro de tu cuenta, la confirmación va a los administradores del programa, así que el círculo se cierra igualmente. Aquí no hay nada que hacer: es un recibo.

La segunda revisión cubre el único punto ciego que deja la confirmación. Como un pago completado por su propio aprobador no envía nada, una sola persona podría aprobar una recompensa pequeña, subirla y pagarla ella misma sin que a nadie le llegue ningún aviso. Este nivel devuelve esa visibilidad: cuando la aprobación, todos los ajustes y el pago los ha realizado la misma persona y el monto final es significativamente superior al que se aprobó en un principio, Kit avisa a los demás administradores del programa.

El umbral de «significativamente superior» no es una cifra fija: se mide contra la configuración de tu propio programa.

• En un programa que usa una matriz de recompensas, el monto es significativo en cuanto acaba por encima del máximo declarado para el nivel de severidad evaluado del informe. Moverse dentro del rango que tu matriz ya autoriza es rutina y no genera ningún aviso.
• En un programa discrecional, sin matriz, el monto es significativo cuando al menos se ha duplicado y ha crecido al menos el Minimum Payout de tu programa. Si has dejado ese mínimo en cero, se aplica el valor por defecto de Kit: $50. Ambas condiciones tienen que cumplirse, así que ni $500 → $550 ni $6 → $12 generan aviso, mientras que $6 → $600 sí.

Esta comprobación tiene una excepción. Si un informe arrastra un ajuste registrado antes del 5 de junio de 2026, su total aprobado no se puede reconstruir a partir del libro mayor (consulta Cómo leer las entradas de ajuste), así que Kit no puede juzgar si el monto creció de forma significativa. En un informe así, un pago llevado de principio a fin por una sola persona genera el aviso de segunda revisión sea cual sea su tamaño, con un texto que se limita a decir que no intervino una segunda persona: nunca afirma un aumento que no ha podido medir.

Las reducciones nunca lo activan, y tampoco el trabajo rutinario de una sola persona: una errata corregida, una subida pequeña. Muchos programas tienen un único administrador activo que, con toda legitimidad, se encarga de cada pago de principio a fin, y un aviso en cada corrección acabaría enseñando a todo el mundo a ignorar precisamente el aviso que nunca debe ignorarse. Para esos pagos, el libro mayor y la cronología del informe siguen siendo el registro.

El texto es objetivo, no acusatorio: quién aprobó qué, quién lo ajustó y a cuánto, quién lo pagó, y un enlace al informe. Es una petición para que un compañero le eche un vistazo al rastro; no es un hallazgo ni una acusación contra quien hizo el trabajo.

Una consecuencia que conviene prever: si tu programa tiene un solo administrador y es esa persona quien lo marcó como pagado, este nivel no tiene a quién avisar y no envía nada. En esa situación, el libro mayor y la cronología son tu único registro, lo cual es una buena razón para nombrar a un segundo administrador del programa.

El descuadre del libro mayor es el nivel que indica que algo va mal. Se envía cuando el monto de la recompensa registrado en el informe ya no coincide con lo que suma su historial en el libro mayor. Todos los caminos dentro de Kit escriben la recompensa y su entrada en el libro mayor a la vez (aprobar, ajustar y revocar mueven ambas cosas al mismo tiempo), así que esto no puede ocurrir con un uso normal. Un descuadre indica que los datos subyacentes se modificaron fuera de la aplicación.

Este nivel no se puede desactivar. Ignora las preferencias de categoría de correo y no incluye enlace para darse de baja, porque una señal sobre la integridad de tu registro financiero no debe poder silenciarse. Llega al aprobador y a todos los administradores del programa, de modo que el descuadre siempre lo ve alguien distinto de quien completó el pago.

Si recibes uno, contacta a soporte: no intentes cuadrar los montos a mano. Trátalo exactamente igual que una infracción de integridad del libro mayor.

Cómo te llegan estos avisos:

• Las notificaciones en la aplicación llegan siempre, en los tres niveles y a todas las personas de la lista de destinatarios. La campana de notificaciones no se ve afectada por las preferencias de correo.
• Los correos de confirmación y de segunda revisión pertenecen a la categoría Security program activity (Actividad del programa de seguridad) de Preferencias de correo electrónico y notificaciones, y se pausan mientras estés en modo vacaciones.
• Los correos de descuadre del libro mayor ignoran la categoría, pero sí respetan el modo vacaciones. Enviarlos a todos los administradores del programa es lo que garantiza que la alerta llegue a alguien mientras el aprobador está fuera.

Estados de desembolso

Estado	Significado
Pending	La fila del desembolso existe pero aún no se ha iniciado. Initiate crea la fila y la hace avanzar en el mismo gesto, así que Pending es un estado transitorio de menos de un segundo, no un estado de la cola; una recompensa a la espera del checklist de preparación no tiene desembolso todavía y está en la pestaña Blocked
Processing	Tu equipo ha iniciado la transferencia fuera de Kit
Completed	Fondos confirmados como recibidos; referencia de transacción registrada: el informe se cierra como Paid en cuanto su ciclo de vida lo permite
Failed	La transferencia no se completó. Para todos los motivos salvo Otra cosa, Kit ya ha pedido nueva información de pago al investigador; no le escribas otra vez. Vuelve a ponerla en cola con Reintentar cuando haya datos nuevos registrados

Si un desembolso falla, el libro mayor registra una entrada disbursement_failed con el código del motivo; la nota escrita se deja fuera a propósito. Finanzas recibe un correo de cancelación solo cuando el fallo lo marcó tu equipo y ya se le había enviado una solicitud de pago; un fallo que finanzas notificó por sí misma no envía nada. Volver a poner el pago en cola requiere un Reintentar manual en la fila fallida, que pasa a ser la acción principal cuando el investigador facilita datos distintos de los que rechazaron el pago. Consulta Cuando falla un pago para ver el ciclo completo.

Documentos fiscales

Los investigadores suben documentos fiscales a través de su portal. Los investigadores con sede en EE.UU. envían un W-9; los investigadores fuera de EE.UU. envían un W-8BEN. Los documentos se almacenan con cifrado en reposo.

Tu equipo revisa los documentos subidos en VDP > Tax Documents:

Estado	Acción
Pending	Documento subido, pendiente de tu revisión
Verified	Has confirmado que el documento es válido: el elemento de preparación queda satisfecho
Rejected	Has rechazado el documento: se notifica al investigador y puede volver a subirlo

Tanto la verificación como el rechazo se registran en el libro mayor con fines de auditoría. Los eventos de documentos fiscales se vinculan al informe más reciente con recompensa otorgada del investigador para dar contexto en el libro mayor.

El libro mayor

Navega a VDP > Ledger para ver el rastro de auditoría financiera inmutable. El libro mayor es de solo adición: las entradas no se pueden editar, modificar ni eliminar.

Cada entrada registra:

• Tipo de entrada: qué sucedió
• Monto: cantidad en dólares, en centavos y moneda
• Actor: el miembro del equipo que realizó la acción. Las entradas registradas desde fuera de tu equipo (un pago confirmado, o un fallo notificado, a través del enlace de finanzas) no tienen ningún usuario de Kit detrás y se muestran como System. Es lo esperado, no una carencia: el nombre de la persona de finanzas queda recogido en la procedencia cifrada del desembolso y se muestra en la fila de la cola como Notificado por …
• Marca de tiempo: cuándo se creó la entrada
• Referencia del informe: el informe de vulnerabilidad vinculado

Cada entrada registra uno de los siguientes tipos:

Tipo de entrada	Cuándo se crea
bounty_approved	Un miembro del equipo aprueba un monto de recompensa para un informe
bounty_adjusted	Un miembro del equipo corrige el monto de la recompensa antes de que se envíe el pago. El monto registrado es la variación, no el nuevo total; consulta Cómo leer las entradas de ajuste
bounty_revoked	Se desestima un informe con recompensa aprobada; la revocación cuenta como débito contra los totales del libro mayor
disbursement_initiated	Un miembro del equipo mueve el desembolso a Processing
disbursement_completed	Un miembro del equipo marca el desembolso como Paid con una referencia de transacción
disbursement_failed	Un desembolso se marca como fallido. La entrada lleva uno de los cinco códigos de motivo fijos; la nota de texto libre se deja fuera del libro mayor a propósito; consulta Cuando falla un pago
tax_document_submitted	Un investigador sube un documento W-8BEN o W-9
tax_document_verified	Un miembro del equipo verifica un documento fiscal como válido
tax_document_rejected	Un miembro del equipo rechaza un documento fiscal; se notifica al investigador, que puede volver a subirlo

Filtra el libro mayor por ID de informe, tipo de entrada o rango de fechas para acotar los resultados. Usa la exportación del libro mayor en Métricas y exportaciones para generar paquetes de pruebas SOC 2.

Cómo leer las entradas de ajuste

bounty_adjusted es el único tipo de entrada cuyo monto es una variación y no un total. Todas las demás entradas registran una cifra absoluta: la recompensa que se aprobó, la suma que se desembolsó, el monto revocado. Un ajuste registra únicamente la diferencia que introdujo la corrección, positiva o negativa.

Esta distinción importa a la hora de conciliar. Una recompensa de $6 corregida a $600 registra un monto bounty_adjusted de $594: ese es el tamaño de la corrección, no una segunda recompensa de $594. Leído como un total, un solo ajuste puede convertir la corrección rutinaria de una errata en un aparente pago en exceso.

Por eso Kit etiqueta los ajustes de forma explícita dondequiera que aparezcan, para que nunca tengas que deducir qué lectura corresponde:

• Cronología del informe: muestra «Recompensa ajustada a $600 USD», el total resultante, de modo que la cifra que ves en el informe es la recompensa en sí.
• Página del libro mayor: muestra la variación con signo explícito, +$594 si sube y -$594 si baja. Un + delante significa «el monto se movió esta cantidad».
• Exportación del libro mayor en CSV: incluye la variación, una columna que indica si ese monto es una variación o una cifra absoluta, y otra columna con el total en el que quedó el ajuste.
• Exportación del libro mayor en PDF y expediente del informe: imprimen la variación con su signo seguida del total que produjo, así: +$594 USD -> $600 USD.
• Slack, donde tu programa publica los eventos de pago: un pago completado sobre una recompensa ajustada indica la aprobación original y el total ajustado, no la variación por sí sola.

Para reconstruir la recompensa aprobada actual solo con el libro mayor, parte de la aprobación, suma todos los ajustes registrados después y resta cualquier revocación. Esa suma es la que Kit compara con el monto registrado en el propio informe (consulta Notificaciones de finalización de pago).

Los ajustes registrados antes del 5 de junio de 2026 son anteriores a este esquema: guardan un monto absoluto y no dejan constancia del total que produjeron. Kit los etiqueta de otra manera en lugar de adivinar: la cronología dice «Recompensa ajustada en», el CSV marca el tipo de monto como unknown y la columna del total resultante se deja vacía. Una entrada antigua nunca se presenta como algo que no puede demostrar.

Integridad del libro mayor

Una verificación de integridad diaria se ejecuta automáticamente para comprobar la coherencia del libro mayor. Recorre cada entrada en orden cronológico y lleva un saldo acumulado: los créditos (bounty_approved, bounty_adjusted) lo aumentan y los débitos (disbursement_completed, bounty_revoked) lo reducen. Si el saldo acumulado llega a ser negativo, la entrada en cuestión se marca como una infracción.

Este saldo acumulado es una comprobación de solvencia y es un cálculo distinto del total aprobado que se describe en Cómo leer las entradas de ajuste. El saldo acumulado también resta los desembolsos completados, porque el dinero que ya ha salido de la empresa deja de contar como pendiente. El total aprobado no lo hace: pagar una recompensa no cambia lo que se aprobó. Usa el saldo acumulado para preguntar «¿cuadra el dinero de este programa a lo largo del tiempo?»; usa el total aprobado para preguntar «¿qué hay aprobado ahora mismo en este informe?».

Cualquier infracción se notifica al sistema de monitoreo de errores de Kit (APM) para que el equipo de ingeniería la investigue: no se envía ningún correo a los administradores de la cuenta. Contacta a soporte si sospechas de una discrepancia en el libro mayor: no intentes resolverla manualmente.

En resumen

• Configura los niveles de la matriz de recompensas con rangos mín/máx apropiados para tu tolerancia al riesgo
• Establece los requisitos de preparación para pagos (documentos fiscales, acuerdo) en la configuración de pagos de tu programa
• Configura un correo de finanzas para que las solicitudes de pago lleguen al equipo que programa los pagos
• Comunica los rangos de recompensa en tu página de política de divulgación antes de que los investigadores envíen informes
• Revisa la cola de Disbursements semanalmente para detectar pagos pendientes
• Revisa la pestaña Failed de forma regular: un pago fallido no genera ningún correo ni notificación en la aplicación
• Lee la fila antes de pulsar Reintentar: si indica que los datos no han cambiado, reenviarás el pago a la misma cuenta fallida
• Utiliza Pedir datos nuevos en las filas fallidas como Otra cosa: ese motivo nunca llega al investigador por sí solo
• Elige Otra cosa antes de desestimar un informe cuyo pago sigue en curso, para que no se le pida al investigador información de pago sobre una recompensa que estás retirando
• Nombra al menos a dos administradores del programa, para que un pago llevado de principio a fin por una sola persona llegue igualmente a un revisor independiente
• Acuerda con tu equipo cuándo una recompensa pasa por una propuesta en lugar de ir directa a la aprobación; Kit no lo impone
• Al conciliar una exportación, lee los montos bounty_adjusted del libro mayor como variaciones, no como totales
• Trata un aviso de descuadre del libro mayor como un asunto para soporte, no como algo que debas arreglar a mano
• Revisa y verifica los documentos fiscales subidos con prontitud para desbloquear los pagos a investigadores
• Exporta el libro mayor trimestralmente como pruebas SOC 2 a través de Métricas y exportaciones

Y ahora qué

• Propuestas de recompensa y votación del equipo: decidir un monto en equipo antes de que se convierta en dinero
• Métricas y exportaciones: KPIs del dashboard, exportaciones de pruebas SOC 2 y karma de investigadores
• El portal del investigador: cómo los investigadores envían su información de pago y documentos fiscales