Permisos y roles en una app financiera: matriz para tu MVP
Para definir los permisos de una app financiera, escribe quién puede consultar, preparar, autorizar y confirmar cada acción, sobre qué cuentas y con qué evidencia. Una lista de roles como «admin» y «usuario» deja demasiadas decisiones abiertas. Esta guía y su matriz descargable convierten esas decisiones en parte del alcance de tu MVP.
Descargar la matriz de permisos para tu MVP (CSV). Incluye ocho situaciones de ejemplo que puedes adaptar en una hoja de cálculo. No pide registro ni contiene datos de clientes.
Empieza por las acciones que cambian algo
Imagina una herramienta donde un operador prepara una solicitud y otra persona la revisa. «Acceso a pagos» puede significar ver un historial, crear un borrador, enviar una instrucción al proveedor o confirmar que el dinero llegó. Son cuatro decisiones distintas. Presupuesta y acepta cada una por separado.
El ejemplo sirve para definir requisitos; no describe una integración bancaria disponible ni supone que tu primera versión deba mover dinero. Si basta con registrar y revisar información, deja la ejecución fuera del alcance inicial. La guía para definir un MVP fintech ayuda a elegir ese recorrido mínimo.
Qué debe tener cada fila de la matriz
| Campo | Ejemplo de requisito | Pregunta para revisarlo |
|---|---|---|
| Actor y alcance | El operador consulta las cuentas asignadas a su equipo. | ¿Qué ocurre con una cuenta de otro equipo? |
| Acción y estado | Puede editar un borrador antes de enviarlo a revisión. | ¿Puede modificarlo después de aprobarse? |
| Confirmación | El revisor ve importe, moneda y destino antes de autorizar. | ¿Cambiar el destino invalida la autorización? |
| Evidencia | La respuesta del proveedor queda asociada al intento. | ¿Un tiempo de espera se presenta como pendiente? |
| Prueba de rechazo | Una petición sin permiso se rechaza en el servidor. | ¿También falla al usar directamente el enlace? |
Un botón oculto no define un permiso
La interfaz puede orientar al usuario, pero el servidor debe comprobar la autorización sobre la acción y el recurso solicitado. Por ejemplo, cambiar el identificador de una cuenta en una URL no debería permitir leer la de otra persona. Tampoco debe bastar conservar un enlace antiguo después de perder un permiso.
La referencia de autorización de OWASP recomienda privilegios mínimos, denegar por defecto y verificar permisos en cada petición. Úsala para redactar criterios de aceptación concretos; completar esta plantilla no certifica la seguridad de una aplicación.
Separa autorización, ejecución y resultado
Una aprobación permite intentar una acción dentro de sus condiciones. No demuestra que un proveedor la haya ejecutado. Una respuesta incompleta o un corte de conexión deben dejar un estado que pueda investigarse, sin repetir a ciegas una instrucción que podría haberse procesado.
Define quién puede investigar ese estado, qué datos puede consultar y quién resuelve una excepción. En el ejemplo, editar importe o destino después de aprobar exige una nueva revisión. Es un requisito posible que debes acordar según tu operación, no una regla universal para todos los productos.
Cómo usar el CSV en una reunión de alcance
- Duplica el archivo y sustituye los roles de ejemplo por los de tu equipo.
- Elimina las acciones que no formarán parte de la primera versión.
- Especifica la relación con cada cuenta: propietario, equipo asignado o ninguna.
- Escribe un caso permitido y uno rechazado para cada acción.
- Asigna un responsable para validar la evidencia de entrega.
Trabaja con ejemplos ficticios. La matriz necesita reglas y estados, no contraseñas, números completos de cuenta o documentos de usuarios. Guárdala en el espacio privado de tu proyecto cuando añadas detalles internos.
Qué llevar a la propuesta de desarrollo
Envía el recorrido principal, la matriz adaptada y dos excepciones que no pueden quedar ambiguas. Con eso podemos discutir integración, esfuerzo y fases con más precisión. Si solo necesitas presentar el proyecto y recibir consultas, revisa primero si conviene una landing, una web o una app.
En Koodev construimos productos como Vakita y P2Pilot; sus permisos responden a usos diferentes. Cuéntanos qué necesita hacer tu equipo para delimitar tu propuesta. Los ejemplos de esta guía son de planificación y no acreditan cumplimiento regulatorio.