Soluções · Serviços financeiros
Uma aplicação para serviços financeiros é julgada pelo que acontece nas suas margens: o que é escrito no registo, o que acontece quando o cliente pede de volta os seus dados, o que se vê na informação pré-contratual e o que acontece quando uma tarefa agendada não é executada. Construímos a mecânica; a política de crédito continua a ser sua.
Já construídoUma plataforma de crédito em produção, verificável externamente hoje: a parte pública é uma aplicação compilada estaticamente com 50 ecrãs, entre os quais quatro calculadoras — crédito, elegibilidade, refinanciamento, gráfico de pagamentos — páginas por tipo de crédito, informação pré-contratual e uma rota pela qual o cliente pede os seus dados pessoais; a parte de negócio é um backend modular em TypeScript com 16 módulos e 18 tabelas no esquema de dados, entre as quais contrato, pagamento, registo de auditoria, pedido relativo aos dados pessoais, documento carregado, instantâneo diário de indicadores e execução de tarefa agendada. O sitemap em produção lista 227 endereços, e as rotas romenas e as russas respondem ambas — verificadas por mim em 06.09.2026. A reserva que dizemos: a prova vem do código e das respostas públicas, não do comportamento interno do servidor — não verificámos em que versão corre a produção nem que todos os 16 módulos estão ativos em live.
Uma empresa de crédito não precisa de um site. Precisa de uma cadeia completa: o pedido entra online, passa por um fluxo de decisão, gera um contrato, produz um gráfico de pagamentos e deixa rasto na auditoria. Cada elo em falta na cadeia transforma-se numa pessoa a copiar dados de um lugar para outro, e em serviços financeiros cada cópia manual é também um problema de conformidade, não apenas de tempo.
A estrutura que construímos reflete isso diretamente nos dados. Na plataforma que citamos, o esquema tem 18 tabelas, e a sua lista diz mais do que qualquer descrição de arquitetura: pedido, contrato, pagamento, código de uso único, sessão, pedido de chamada, modelo de notificação, registo de notificações, instantâneo diário de indicadores, execução de tarefa agendada, artigo, redirecionamento de endereço, definição de visibilidade, nota interna, registo de auditoria, documento carregado, pedido relativo a dados pessoais. O backend está dividido em 16 módulos, entre os quais um dedicado exclusivamente aos direitos do titular dos dados.
A parte pública não é decoração: quatro calculadoras — crédito, elegibilidade, refinanciamento e gráfico de pagamentos — mais páginas separadas por tipo de crédito e a informação pré-contratual. No crédito ao consumo, a informação pré-contratual não é uma página de imagem: é a obrigação de mostrar as condições antes de a pessoa se comprometer. Tratamo-la como um requisito do produto, não como um texto jurídico colado no fim. As rotas romenas mantêm-se sem prefixo, e as russas seguem num segmento próprio, com etiquetas canónicas e alternativas geradas a partir da língua da rota ativa.
E o limite que deve ser dito antes do contrato: o fluxo de decisão sobre os pedidos — as regras, os limiares, a aprovação — é seu. Nós construímos a mecânica pela qual o pedido circula, é documentado e se torna contrato. Não escrevemos a política de crédito e não assumimos a avaliação de um requerente; são decisões com consequências jurídicas que pertencem à instituição autorizada.
Qué incluye
O pedido entra online e vive como entidade própria, com estado visível e com ecrã de acompanhamento para o cliente. Os documentos carregados têm a sua tabela, o contrato tem a sua tabela, o pagamento a sua. A diferença em relação a um formulário que envia um e-mail é que, daqui a três meses, se pode responder com dados à pergunta “o que aconteceu com o pedido de 12 de março”.
O contrato e o gráfico não são compostos manualmente num documento separado: saem dos dados do pedido aprovado. É a única variante em que o valor no contrato e o valor no gráfico não podem divergir, e o cliente que telefona com o documento na mão fala da mesma coisa que o operador que olha para o sistema.
Crédito, elegibilidade, refinanciamento e gráfico de pagamentos — ecrãs separados, públicos, sem autenticação. No crédito ao consumo, a calculadora é a primeira interação real: a pessoa quer ver a prestação antes de falar com alguém. E o refinanciamento é uma calculadora diferente da de crédito, não a mesma com outras etiquetas.
Página própria, não um parágrafo no rodapé. A razão é prática: se a informação não estiver no trajeto que a pessoa percorre antes de assinar, não cumpre a sua função nem para ela, nem para a instituição. O texto é seu e dos seus juristas; nós construímos o lugar, o momento e a rastreabilidade.
Existe uma página pública pela qual o cliente pede os seus dados pessoais, um módulo de backend dedicado e um ecrã de administração para os pedidos recebidos, além de uma tabela onde eles vivem. A consequência prática: o prazo legal de resposta pode ser cumprido sem que alguém abra manualmente a base de dados — e pode ser demonstrado, daqui a um ano, que foi cumprido.
O diário de auditoria é uma tabela própria, distinta das notas internas dos operadores. A separação conta numa verificação: uma coisa é o registo técnico do que aconteceu, outra é o que um colega escreveu sobre um dossier. Misturadas, a primeira torna-se ilegível e a segunda torna-se documento.
Existe uma tabela para as execuções das tarefas agendadas e uma para os instantâneos diários de indicadores. Numa plataforma financeira, uma tarefa que não correu três noites seguidas é um problema mais grave do que uma página em baixo: não se vê do exterior, mas altera os números. Por isso, a execução é registada, não presumida.
As rotas romenas permanecem sem prefixo, as russas seguem por um segmento próprio, com etiquetas canónicas e alternativas geradas a partir da língua da rota ativa. No mapa do site em produção há 227 endereços. Para uma empresa de crédito na República da Moldávia, a parte russa não é uma tradução de cortesia — é metade dos solicitantes.
Verificações antes da publicação, migrações de base de dados executadas com comando separado em produção, geração de secrets, cópia de segurança e restauro da base — tudo como scripts no repositório, não como passos de um documento. Num sistema que gere contratos e pagamentos, «restauro» tem de ser um comando que você tentou, não uma intenção.
Traseul
O que significa um pedido submetido, um pedido aprovado, um pagamento recebido; o que acontece com um pedido ao qual não se respondeu; o que falha fechado quando um serviço externo não responde. Entregamos o documento de vocabulário e invariantes, porque, numa plataforma financeira, um termo usado em dois sentidos torna-se, mais tarde, dois números diferentes em dois relatórios.
O registo de auditoria e o registo documental não são adicionados no fim; fazem parte da primeira versão que funciona. Entregamos o fluxo completo do pedido ao contrato, com o seu rasto, em dados de teste — não ecrãs que ficam bonitos sobre uma base vazia.
Os ecrãs públicos, as calculadoras, as páginas por tipo de crédito e a informação pré-contratual, com os endereços romenos sem prefixo e os russos no seu próprio segmento, com etiquetas canónicas corretas. Entregamos o mapa do site gerado a partir dos dados e a verificação de que ambas as versões respondem.
Verificação antes da publicação, migrações em produção com comando separado, geração de secrets, cópia de segurança e restauro — comprovados, não apenas escritos. Entregamos o repositório, o documento de colocação em funcionamento e os acessos. O restauro da base é demonstrado na entrega, uma vez, perante vocês.
Os dados
As regras diferem de setor para setor. Estas são as que se aplicam nos serviços financeiros.
Un caso
A situação
O requisito inicial num projeto de concessão de crédito soa quase sempre igual: «um site com formulário de pedido». O problema surge no segundo mês, quando alguém pergunta onde está o contrato, quem alterou o dossier e como respondemos a um pedido de acesso a dados pessoais dentro do prazo legal.
Qué construimos
Construímos a plataforma em duas metades, no mesmo repositório. A parte pública é uma aplicação compilada estaticamente, com 50 ecrãs: quatro calculadoras — crédito, elegibilidade, refinanciamento, calendário de pagamentos — páginas por tipo de crédito, informação pré-contratual, acompanhamento do estado do pedido e uma página através da qual o cliente solicita os seus dados pessoais. A parte de negócio é um backend modular em TypeScript, com 16 módulos — entre os quais autenticação, direitos por função, fluxo dos pedidos, documentos, pagamentos, notificações, tarefas agendadas e um dedicado aos direitos do titular dos dados — sobre um esquema com 18 tabelas: pedido, contrato, pagamento, código de uso único, sessão, documento carregado, registo de auditoria, pedido relativo a dados pessoais, execução de tarefa agendada, instantâneo diário de indicadores e o resto.
Qué salió
A cadeia é completa: o pedido entra, circula, produz contrato e calendário, e cada passo deixa rasto. Os pedidos relativos a dados pessoais têm percurso próprio, com ecrã de administração, por isso o prazo legal pode ser cumprido e demonstrado. A parte pública é verificável externamente: 227 endereços no mapa do site, com ambas as versões linguísticas ativas.
Qué no dice el caso
A prova vem do código e das respostas públicas, não do comportamento interno do servidor: não verificámos em que versão a produção corre, nem que todos os 16 módulos estão ativos em live. O fluxo de decisão sobre os pedidos — regras, limiares, aprovação — pertence ao cliente; nós construímos a mecânica, não a política de crédito.
Perguntas
Vocês. As regras, os limiares e a aprovação são a política da instituição autorizada, não do fornecedor de software. Nós construímos a mecânica pela qual o pedido circula, é documentado, torna-se contrato e calendário de pagamentos, e deixa rasto. Um fornecedor que assume a decisão de crédito vende algo que não tem o direito de vender.
Existe uma página pública através da qual ele faz o pedido, um módulo de backend dedicado, um ecrã de administração e uma tabela onde o pedido vive. Portanto, é possível responder dentro do prazo e provar depois. O que não é uma decisão técnica: o que pode ser apagado e o que tem de ser conservado de acordo com a legislação financeira — isso é definido com os vossos juristas, antes da implementação.
A partir dos dados do pedido aprovado, juntamente com o calendário de pagamentos — ambos da mesma fonte, para que não possam diferir. O que fica a vosso cargo é o conteúdo do contrato e as suas condições. Um contrato composto manualmente num documento separado é o local clássico onde aparecem dois valores diferentes para o mesmo empréstimo.
Porque no crédito ao consumo a informação tem de estar no percurso que a pessoa percorre antes de se vincular, e não num rodapé. Tratamo-la como parte do produto: o lugar, o momento e a rastreabilidade são nossos, o texto é dos vossos juristas.
Pelo menos os que correspondem a decisões diferentes. Na plataforma que citamos são quatro — crédito, elegibilidade, refinanciamento, calendário de pagamentos — porque o refinanciamento não é o mesmo cálculo que o novo crédito, e o calendário responde a outra pergunta do que a prestação. Um único calculador com muitos campos é mais difícil de usar do que quatro simples.
Não, e é uma regra, não uma preferência: construímos e testamos com dados de teste. O acesso a dados reais, quando necessário, é feito com pessoas nomeadas, por um período definido e com registo no log. Num sistema financeiro, «precisei de olhar para a produção» é uma frase que deve aparecer num log, e não numa conversa.
Isso vê-se, porque as execuções são registadas numa tabela própria, ao lado dos instantâneos diários de indicadores. É importante precisamente porque uma tarefa que não foi executada não produz nenhum sintoma visível do exterior — o site responde, os ecrãs parecem bons, mas os números deixam de se mover.
Nenhum número de volume, de taxa de juro, de quantidade de pedidos ou de clientes, mesmo que esteja exibido publicamente no seu site — porque é a afirmação dele, não a nossa medição. O que podemos mostrar é a estrutura: quantos módulos, que tabelas, que ecrãs públicos, o que é verificado na publicação. A mesma regra aplicar-se-á também ao vosso trabalho.
A parte pública pode ser verificada agora: o mapa do site tem 227 endereços, e as versões romena e russa de um calculador respondem ambas. A parte de backend é lida a partir do código — módulos e esquema de dados — e não do comportamento do servidor: não verificámos em que versão a produção está a correr e nem se todos os módulos estão ativos em live, e preferimos escrever isso do que deixar a impressão contrária.
Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.