The Ten-Second Build: o programa de envio instantâneo de um IME

Sumário executivo

Uma instituição de moeda eletrónica (IME) contratou o hub para construir um programa de envio instantâneo antes do prazo SEPA Instant de 9 de abril de 2027. O programa entregou operações de pagamento 24/7, uma janela de processamento de 10 segundos e uma ponte de liquidez em tempo real. O go-live foi Q1 2027, antes do prazo regulatório.

Os detalhes do cliente são anonimizados perante o regime de rotulagem do Cap. 10. Nenhum leitor razoável pode retro-engenheirar o cliente a partir da informação aqui publicada.

Contexto do cliente

O cliente é um IME da área do euro com um portfólio de serviços de pagamento que abrange remessas, acquiring de comerciantes e pagamentos B2B a fornecedores. A infraestrutura de pagamentos existente do IME era orientada a lotes: pagamentos eram enfileirados durante o dia útil e liquidados em lotes no final do dia via STEP2. O IME não tinha capacidade de pagamentos instantâneos.

O perímetro regulatório do IME colocava-o claramente na obrigação de envio de 9 de abril de 2027. Ao contrário dos bancos, o IME não tinha uma ligação TIPS ou RT1 existente. Tudo teve de ser construído do zero.

Desafio de negócio

O prazo de 9 de abril de 2027 exige três capacidades que o IME não tinha:

1. Processamento de pagamentos 24/7. SCT Inst opera 24 horas por dia, 365 dias por ano. A equipa de operações do IME trabalhava em horário comercial, segunda a sexta. Sem cobertura de fim de semana. Sem cobertura noturna. Sem cobertura de feriados.

2. Janela de processamento de 10 segundos. Cada pagamento deve ser processado, rastreado para fraude, rastreado para sanções, verificado quanto a liquidez e submetido à infraestrutura de compensação em 10 segundos. O pipeline de processamento em lote do IME demorava 90 segundos por pagamento apenas para rastreio de fraude e sanções.

3. Gestão de liquidez em tempo real. SCT Inst liquida individualmente, não em lote. A função de tesouraria do IME financiava a conta STEP2 uma vez por dia. Monitorização e top-up de liquidez em tempo real não existiam.

Abordagem

O programa correu em três fluxos de trabalho paralelos durante 14 meses:

Fluxo 1: Integração com infraestrutura de compensação

Ligou o IME a TIPS como infraestrutura de compensação primária, com RT1 como backup. Construiu um router de pagamentos que podia falhar entre TIPS e RT1 sem perder pagamentos em curso. O router foi testado com 10.000 pagamentos num ambiente equivalente à produção antes do go-live.

Fluxo 2: Reconstrução do pipeline de processamento

Substituiu o pipeline de rastreio de fraude e sanções em lote por um pipeline de streaming que processa cada pagamento em menos de 3 segundos. O pipeline usa um motor de regras para primeira passagem e um modelo de machine learning para segunda passagem. Pagamentos que passam ambas as passagens são submetidos à infraestrutura de compensação. Pagamentos que sinalizam para revisão são encaminhados para uma fila de analista humano.

A fila de analista humano é equipada 24/7. O IME subcontratou cobertura noturna e de fim de semana a um fornecedor de operações geridas. O fornecedor segue um runbook escrito pela equipa do hub. O runbook cobre 47 cenários de exceção.

Fluxo 3: Ponte de liquidez

Construiu um sistema de monitorização e top-up de liquidez em tempo real. O sistema monitoriza o saldo da conta TIPS a cada 5 segundos. Quando o saldo cai abaixo de um limiar configurado, o sistema aciona automaticamente um top-up da conta em euro pré-financiada do IME num banco de primeira linha. O top-up é executado via chamada API, não transferência manual.

A ponte de liquidez foi o componente de maior risco. Uma falha na ponte significaria que o IME não poderia enviar pagamentos. A ponte foi construída com ligações bancárias redundantes: se a API do banco primário estiver indisponível, o sistema falha para um banco secundário. Se ambos estiverem indisponíveis, o sistema alerta a equipa de tesouraria e pausa a submissão de pagamentos outbound.

Solução

A construção de envio instantâneo entrou em produção em Q1 2027, seis semanas antes do prazo de abril. A primeira semana de processamento em produção mostrou:

Métrica	Valor	Notas
Janela de processamento (mediana)	4,2 segundos	Bem dentro do requisito de 10 segundos
Janela de processamento (P99)	8,7 segundos	Dentro do requisito de 10 segundos
Débito de pico	340 TPS	Excedeu o alvo de design de 200 TPS
Taxa de passagem de rastreio de fraude	97,3%	2,7% encaminhada para revisão humana
Ativações da ponte de liquidez	12 na semana 1	Todas bem-sucedidas, sem intervenção manual
Failover de infraestrutura de compensação	0	TIPS estável ao longo do período

Resultados

• Go-live: Q1 2027, seis semanas antes do prazo de 9 de abril
• Janela de processamento: mediana 4,2 segundos, P99 8,7 segundos
• Débito de pico: 340 transações por segundo
• Zero incidentes regulatórios nos primeiros 90 dias
• Operações 24/7 mantidas através de fins de semana e feriados sem downtime não planeado

Lições

1. Começar a integração com a infraestrutura de compensação primeiro. Tem o maior tempo de entrega. O processo de onboarding TIPS demorou 4 meses, condicionado pelos requisitos de validação e testes do BCE.

2. Subcontratar operações 24/7 se não as conseguir equipar. O IME não conseguiu contratar uma equipa de operações 24/7 em 14 meses. A subcontratação a um fornecedor de operações geridas foi a escolha pragmática. O runbook é o deliverable crítico, não o modelo de staffing.

3. Construir a ponte de liquidez com redundância desde o primeiro dia. Uma única ligação bancária é um ponto único de falha. A ponte deve ter pelo menos duas ligações bancárias, e o failover deve ser automático.

4. Testar com volumes equivalentes à produção antes do go-live. O teste de 10.000 pagamentos num ambiente equivalente à produção apanhou três defeitos de integração que teriam causado falhas de go-live. Testar com 100 pagamentos não os teria apanhado.

---

Caso de estudo anonimizado. Permissão do cliente obtida perante o fluxo de 5 passos do Cap. 10. Detalhes identificadores revistos com o cliente. Nenhum leitor razoável pode retro-engenheirar o cliente a partir da informação aqui publicada. Data de re-verificação: agosto de 2027.