Pagamentos de varejo: salário, boleto e débitos

No cenário oficial v14 Process Salary Payments for Internal Accounts, view 54620, o repositório ainda mostra linhas de vida com nomes antigos: Payment Execution e Payment Order. As release notes do BIAN 14.0 anunciam as trocas: Payment Order passa para Payment Confirmation; Payment Execution passa para Payment Settlement. A ordem abaixo é minha leitura didática da jornada, não uma sequência normativa extraída do repositório.

A folha começa em Corporate Payroll Services, domínio de padrão Fulfill, cuja ficha diz que ele processa pagamentos líquidos de salário para empregados de clientes corporativos. Ele recebe a instrução da folha. Corporate Current Account, também Fulfill, bloqueia o total na conta da empresa antes do primeiro crédito. Essa reserva é o ponto que separa uma arquitetura séria de uma fila otimista.

Depois, Payment Confirmation confere e reserva. Payment Settlement move os fundos, passando por Internal Bank Account, que é Track e funciona como conta intermediária. Current Account credita Marina, personagem fictícia. Position Keeping, também Track, registra a posição. Correspondence, de padrão Operate, avisa fora do caminho crítico.

A lição dura: folha é um lote de milhares de pagamentos pequenos. Use idempotência por crédito, evento com id do lote, reserva do total antes do primeiro crédito, e comunicação assíncrona para o aviso.

A Resolução CMN 5.058/2022 dá restrições concretas para conta-salário. Ela só aceita créditos da entidade contratante, no art. 3º. Não movimenta por cheque, no art. 4º. É vedada para titular pessoa jurídica, no art. 2º, § 3º. A portabilidade salarial acontece a pedido do beneficiário, no art. 7º.

Essas regras não significam que você precisa criar um domínio chamado conta-salário no mapa. Eu procurei esse domínio na v14 e ele não aparece. A diferença está no produto, na elegibilidade, na origem aceita para crédito e na rotina de portabilidade, não numa nova capacidade universal de conta.

O erro clássico é colocar tudo em Current Account como exceção escondida. Isso funciona até alguém tentar auditar por que uma transferência foi recusada ou por que um crédito de origem errada entrou. A regra precisa estar modelada como produto, aplicada no ponto de crédito, e rastreável como decisão.

Quando o crédito vem de outro banco, o cenário oficial Handle Incoming Credit Transfer, view 55000, usa Correspondent Bank Operations, Payment Order e Payment Execution, todos obsoletos. Nesta aula, leia Payment Rail no lugar de Correspondent Bank Operations, e mantenha Regulatory Compliance para a checagem de lavagem de dinheiro, indicada pela mensagem Conduct AML Check.

A Resolução BCB 443/2024 define os papéis do boleto: beneficiário, pagador, instituição emissora, instituição recebedora, instituição destinatária e base centralizada, que serve como repositório para registro e consulta dos boletos. O VR Boleto é R$ 250.000,00, no art. 19.

Quando o valor é igual ou superior ao VR Boleto, a transferência deve ocorrer no mesmo dia pelo STR, encaminhada para liquidação em até 60 minutos após o pagamento, conforme art. 16, I e § 1º. Abaixo desse valor, a recebedora pode usar compensação multilateral ou o procedimento do STR, conforme art. 16, II. Devoluções e acertos detectáveis por automação devem ocorrer até o dia útil seguinte ao da liquidação, conforme art. 18, § 1º.

STR aqui não é detalhe de infraestrutura. É liquidação bruta em tempo real, irrevogável, sem saldo negativo. Essa frase muda desenho de risco, fila, retry e conciliação.

Minha leitura: pagar boleto é uma jornada adaptada da do Pix. A frente usa Payment Order Initiation, Payment Orchestration e Payment Confirmation, cuja ficha lista checagens de risco, incluindo lavagem de dinheiro (AML), e Fraud Evaluation testa o risco de fraude. Depois entram Payment Rail, Payment Settlement e Current Account. Emitir boleto, como não há domínio de boleto na v14, eu colocaria como desvio registrado em ADR, perto de Cash Management And Account Services, de padrão Fulfill, com recebimentos pelo Payment Rail.

Débito automático costuma ser ensinado como uma autorização simples. No mapa, eu separo três coisas: o serviço que executa pelo lado do credor, o mandato que prova a autorização, e o consentimento que expressa preferência e restrição do cliente.

Na v14, Direct Debit Collection e Direct Debits Service estão obsoletos, sem substituto citado nas release notes. O domínio registrado Direct Debit tem padrão Fulfill e fica no lado do credor. Direct Debit Mandate tem padrão Catalog e guarda os mandatos. Customer Consent é novo, sem padrão citado aqui, e registra preferências e restrições do cliente para débitos e pedidos de pagamento.

Globalmente, existe o cenário oficial EXT Record Core SEPA Direct Debit Mandate at Creditor Bank, view 55394, para o esquema europeu. Eu não traria regra de SEPA para esta aula, porque o ponto didático é outro: mandato não é cobrança, consentimento não é liquidação, e trilho não é produto.

Se você colocar tudo num único serviço chamado débito automático, o sistema até passa no demo. A primeira auditoria pede quem autorizou, qual consentimento estava vigente, qual cobrança usou o mandato, e qual trilho liquidou. Sem essas fronteiras, a resposta vira busca em log.