RBAC É aí que o gateway começa a compensar o investimento. Numa plataforma bancária multilocatária, o acesso não pode ser amplo apenas porque o agente é “interno”. Cada locatário necessita da sua própria matriz de permissões. Um comerciante que utilize apenas a iniciação de pagamentos não deve ter acesso a ferramentas de KYC. Um agente de apoio numa região não deve ter acesso aos controlos de cartões de outra região. Um fluxo de trabalho que necessite apenas de uma explicação do saldo não deve ter acesso à preparação de transferências.
Validação do esquema é o próximo filtro. O gateway deve validar cada pedido em relação às especificações OpenAPI aprovadas ou a contratos equivalentes. Isto permite detetar cargas de dados inválidas: formato de moeda incorreto, falta do ID do beneficiário, canal de pagamento não suportado, intervalo de datas impossível, pedido de estado KYC malformado. O modelo pode ser eloquente e, mesmo assim, produzir uma carga de dados que o sistema deve rejeitar.
Fluxos de trabalho de aprovação são os pontos em que o modelo sem custódia se concretiza. O agente pode preparar uma ação, mas as operações de alto risco requerem uma fila de espera, tais como limites de montante, novos beneficiários, estado suspeito da conta, KYC incompleto, sinais elevados de fraude ou políticas específicas do utilizador. O gateway deve criar o item de aprovação, notificar o aprovador, monitorizar as regras de tempo limite e devolver um estado claro ao utilizador ou ao operador.
Registo de auditoria tem de ser integrado no percurso. Para cada pedido, o gateway deve registar um registo de apenas adição. Este registo deve incluir o inquilino, o utilizador, o canal, o estado do fluxo de trabalho, a ferramenta, os parâmetros após a expurgação, o resultado da validação, o estado de aprovação, a resposta a jusante e o ID de correlação. As equipas de conformidade não precisam de uma transcrição elegante. Precisam de um registo claro que explique por que razão o sistema permitiu ou bloqueou a ação.
Há uma distinção que vale a pena estabelecer desde o início: o registo comprova o que foi executado, não quem tinha competência para o fazer. Um registo pode demonstrar perfeitamente que uma transferência foi efetuada de A para B ao abrigo de um determinado token. Por si só, não pode demonstrar que a ação foi autorizada por um mandante reconhecido por ambas as partes, nem que a autorização ainda não tivesse sido revogada. Num fluxo de inquilino único, essa lacuna é invisível, porque o registo e os registos de autoridade se encontram no mesmo local. No momento em que surge um litígio envolvendo um inquilino ou uma contraparte, essa lacuna torna-se o problema principal. Por isso, o registo deve indicar a autoridade: qual o mandato que autorizou a chamada, em que âmbito, e se ainda era válido naquele momento. Abordo este ponto em pormenor no meu artigo Um mandato não é sinónimo de governação.
Disjuntores Isso é importante porque os prestadores de serviços bancários apresentam falhas monótonas, como tempos de espera esgotados, interrupções parciais, respostas lentas, estados desatualizados e limites de taxa. O gateway deve detetar esse padrão, tentar novamente com um mecanismo de recuo quando for seguro fazê-lo, interromper chamadas repetidas quando não for e oferecer ao utilizador uma alternativa útil. “Provedor AML indisponível, tente novamente mais tarde” é melhor do que deixar o agente entrar num ciclo vicioso, inventar um estado ou continuar a insistir num serviço com desempenho reduzido.
Âmbito do token limita o raio de impacto. Uma chamada à ferramenta deve receber o acesso mínimo necessário para essa solicitação específica, inquilino, utilizador e estado do fluxo de trabalho. Os tokens de curta duração e com âmbito restrito são muito mais seguros do que as credenciais de serviço de longa duração que circulam na camada do agente. Se algo correr mal, a solicitação falhada deve ter um impacto limitado.
Contrate-nos
Sobre nós