Cliente: cadastro, conheça seu cliente e abertura de conta
O registro mais reutilizado do banco, o que a norma pede e um nome obsoleto escondido no cenário oficial.
4 min de leitura
Assista ao documentário desta parte: Parte 2 · Um banco por dentro (~68 min)A Marina, personagem fictícia, baixa o app do banco, fotografa o documento e tira uma selfie. Para ela, isso parece cadastro. Para a arquitetura, nasce o registro mais reutilizado do banco: quem é essa pessoa, quais dados sustentam essa identidade e quais contratos podem ser criados a partir dela.
O cadastro não é tela, é fonte de verdade
A pergunta perigosa aqui não é "qual tela captura o documento?", é "quem tem autoridade para dizer quem é a Marina depois que a tela fecha?". Em banco, cadastro vira dependência de quase tudo: conta, contrato, cartão, crédito, cobrança, atendimento, prevenção à lavagem de dinheiro e auditoria.
No cenário oficial v14 Execute Customer Onboarding API version (view 55753), aparecem linhas de vida como Session Dialogue, Correspondence, Customer Agreement, Party Reference Data Directory, Location Data Management, Party Lifecycle Management, Regulatory Compliance, Issued Device Administration e Document Directory. A ordem que uso para ensinar essa jornada é leitura minha: Session Dialogue conduz as telas; Party Reference Data Directory registra dados e contatos; Document Directory guarda documentos; Location Data Management confere o endereço; Regulatory Compliance avalia as checagens regulatórias; Party Lifecycle Management ativa o relacionamento; Customer Agreement formaliza o contrato mestre; Issued Device Administration emite as credenciais.
Essa distinção parece acadêmica até o primeiro incidente. Se todo sistema escreve um pedaço do cadastro, ninguém sabe qual CPF, endereço, telefone ou consentimento vale quando há divergência. Um único dono para o registro da pessoa não é preciosismo de modelagem, é a diferença entre operar uma instituição auditável e manter uma colcha de retalhos com tela bonita.
Na prática, eu separo cadastro, documento, checagem regulatória, contrato mestre e contrato de produto porque cada um envelhece em ritmo diferente. Misturar tudo no sistema de conta parece rápido no primeiro sprint, mas cobra juros em toda auditoria, reabertura de cadastro e produto novo.
Conheça seu cliente tem estado, vencimento e evento
Na v14, eu procurei e não encontrei um Service Domain chamado KYC ou conheça seu cliente. Isso importa. Quando a arquitetura inventa um domínio genérico chamado KYC, ela costuma esconder três coisas diferentes: dados da parte, evidências documentais e avaliação regulatória.
O BIAN traz cenários oficiais mais específicos. Perform Customer Due Diligence Assessment (view 55550) envolve Regulatory Compliance, Guideline Compliance, Party Lifecycle Management, Legal Entity Directory e Party Reference Data Directory. Perform Regulatory KYC Analysis (view 55240) envolve Party Lifecycle Management, Customer Credit Rating, Legal Entity Directory, Correspondence, Regulatory Compliance, Customer Behavior Insights e Information Provider Operation.
No Brasil, a Circular BCB 3.978/2020, art. 13, fala em procedimentos destinados a conhecer o cliente, com identificação, qualificação e classificação. O § 1º, I, exige medidas reforçadas para categorias de maior risco, conforme a avaliação interna de risco. Isso não combina com checkbox único no primeiro dia.
A ficha do Party Lifecycle Management diz que ele acompanha o estado do relacionamento da parte com o banco desde as checagens iniciais e lista reavaliações periódicas. Seus Behavior Qualifiers no YAML são Qualification, Documentation, Precedents e IdentityProofing. Eu não cito o padrão funcional dele: a descrição do control record está vazia no YAML, e o nome do control record só sugere um padrão, sem confirmar.
Da Marina à conta corrente
A jornada separa identidade, evidência, avaliação, contrato mestre, contrato de produto e conta. A linha Payment Order aparece como armadilha do cenário publicado e deve ser validada contra a v14.
- Session Dialogue · telas e sessão
- Party Reference Data Directory · dados e contatos
- Document Directory · documento e selfie
- Location Data Management · endereço
- Regulatory Compliance · avaliação regulatória
- Party Lifecycle Management · estado do relacionamento
- Customer Agreement · contrato mestre
- Customer Product And Service Eligibility · elegibilidade
- Sales Product Agreement · contrato da conta
- Product Directory · condições da conta
- Current Account · conta aberta
- Issued Device Administration · credenciais e débito
- Financial Accounting · registro contábil
- Payment Order · obsoleto na v14
- Payment Confirmation · substituto anunciado
Abrir conta é outra jornada
Depois que a Marina existe como parte conhecida, vem a pergunta de produto: ela pode abrir qual conta, sob quais condições e com qual contrato? O cenário oficial Handle Request to Open Retail Current Account (view 54760) ajuda, mas precisa ser lido com validador na mão.
A ordem que uso é esta: Product Directory traz as condições; Customer Product And Service Eligibility diz para quais contas ela é elegível; Party Lifecycle Management verifica; Sales Product Agreement cria o contrato do produto; Current Account abre a conta; Issued Device Administration emite o cartão de débito; Financial Accounting registra.
Customer Agreement é o contrato mestre. Sales Product Agreement é o contrato de cada produto. Separar os dois evita reescrever o contrato mestre cada vez que a Marina contrata uma conta, um cartão ou outro produto. Essa separação também deixa claro onde fica a obrigação geral de relacionamento e onde fica a condição específica daquele produto.
A armadilha é que o próprio cenário publicado na v14 ainda lista a linha de vida Payment Order, com a mensagem Create Payment Order for Fees and Charges. Payment Order está obsoleto na v14, e Payment Confirmation aparece como substituto anunciado nas release notes. Copiar cenário sem conferir nome por nome traz nome velho para o desenho novo.
Onde cada responsabilidade deve morar
| Responsabilidade | Domínio adequado | Erro comum | Por que separo |
|---|---|---|---|
| Dados e contatos da pessoa | Party Reference Data Directory, padrão Catalog | Cada sistema escreve um pedaço | Um dono reduz divergência em auditoria e atendimento |
| Endereço | Location Data Management, padrão Catalog | Endereço preso no sistema de conta | Endereço serve mais de uma relação e muda no tempo |
| Checagem regulatória | Regulatory Compliance, padrão Assess | KYC tratado como checkbox único | Risco tem classificação, reforço e reavaliação |
| Contrato mestre | Customer Agreement, padrão Agree Terms | Misturar contrato geral com contrato de produto | O relacionamento não deve ser refeito a cada produto |
| Contrato de produto | Sales Product Agreement, padrão Agree Terms | Abrir conta sem contrato específico | Cada produto tem condição própria |
| Credencial e dispositivo | Issued Device Administration, padrão Allocate | Cartão e credencial viram detalhe da conta | Credencial tem ciclo de vida próprio |
Cadastro e abertura de conta
Segunda de manhã
Perguntas que sempre aparecem
Posso criar um domínio interno chamado KYC?
Pode, se você souber que está criando uma convenção interna, não copiando um Service Domain v14. Eu prefiro mapear para Party Lifecycle Management, Regulatory Compliance, Party Reference Data Directory e Document Directory, conforme a responsabilidade concreta.
Por que não colocar tudo no sistema de conta?
Porque conta é produto. Pessoa, documento, endereço, estado regulatório e contrato mestre são usados antes, durante e depois da conta. Acoplar tudo à conta parece simples, mas torna reuso e auditoria mais caros.
O que faço com Payment Order no cenário de abertura de conta?
Marque como nome obsoleto na v14 e valide a troca por Payment Confirmation no seu desenho. A lição não é decorar o substituto, é nunca importar cenário sem conferir cada Service Domain contra a versão certa.