Recompensas y pagos

Por qué es importante

Las recompensas y los pagos requieren el complemento de VDP ($49/mes). Desbloquean 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 —lo pagado, pagado está—.
• 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 realmente un toque, con una cifra de «desbloquea N pagos / X USD». Este recuento es deliberadamente honesto: 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á. El número refleja lo que un toque puede desbloquear de verdad, no ilusiones.

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. Dar un toque requiere el complemento de VDP y 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 realmente 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 estrictamente 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

En la mayoría de las empresas, la persona que programa el pago está en finanzas, no en seguridad: vigila una bandeja de entrada como [email protected] y no tiene cuenta en Kit. El traspaso a finanzas cubre esa brecha: Kit envía por correo a tu equipo de finanzas todo lo que necesitan para programar el pago, y ellos mismos lo confirman a través de un enlace seguro.

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 cuatro 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

El correo de los tres primeros motivos nombra el motivo en términos que el investigador entiende, reitera que el importe íntegro sigue reservado para él 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, 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.

Lo que ve tu equipo. La fila pasa a la pestaña Failed de la cola y cuenta la historia completa: un chip de Pago fallido con el motivo, Notificado por … cuando lo registró finanzas, la nota escrita, Se ha pedido nueva información de pago al investigador cuando sale ese correo y Nueva información de pago registrada cuando responde. 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, igualmente, lleva solo el código.

Volver a poner el pago en cola. El reintento es manual y exclusivo del equipo — el investigador no puede activarlo. El botón Reintentar está en la fila fallida y se mantiene como acción secundaria hasta que el investigador facilita datos nuevos, momento en el que pasa a ser la acción principal. Es una señal de preparación, no decoración: reintentar antes de tiempo solo vuelve a enviar el dinero a la misma cuenta muerta.

Reintentar emite una nueva solicitud de pago con una nueva referencia y un nuevo enlace. El enlace de confirmación antiguo queda muerto, y el detalle del fallo desaparece de la cola junto con el intento al que pertenecía — el libro mayor conserva el registro. 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.

stateDiagram-v2
    state "Processing" as Processing
    state "Failed" as Failed
    state "El investigador actualiza su información de pago" as Updated
    state "Processing (nuevo desembolso)" as Retried

    [*] --> Processing: Iniciar
    Processing --> Failed: Marcado como fallido por tu equipo o por finanzas
    Failed --> Updated: Correo al investigador — solo los tres primeros motivos
    Updated --> Retried: Reintentar
    Retried --> [*]: Marcar pagado

    note right of Retried
      Reintentar no revive el pago fallido.
      Inicia uno nuevo, así que la referencia
      y el enlace antiguos quedan muertos.
    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. Es deliberado. 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 realmente 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 tres de los cuatro motivos de fallo, 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 deliberadamente. 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 es un Reintentar manual en la fila fallida, que se convierte en la acción principal de la fila cuando el investigador facilita información que funcione. 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 cuatro códigos de motivo fijos; la nota de texto libre se deja fuera del libro mayor deliberadamente — 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 realmente 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 deliberada — un pago fallido no genera ningún correo ni notificación en la aplicación
• 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

Siguientes pasos

• 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