Uma jornada de abertura de relacionamento PJ construída sobre blocos que já operam em produção — e, no centro dela, uma política de aceitação que o compliance do Pine escreve, simula, publica e revisa, sem release e sem depender de fornecedor.
Os dois documentos do banco e as sete maquetes descrevem uma jornada em dois momentos: um modal sobre o site institucional que pede CNPJ, confirma os dados públicos, pergunta quem é a pessoa e responde “estamos verificando; confirmação por e-mail em até 24 horas”; e, depois, a jornada stateful de documentos, biometria dos representantes legais e assinatura. Esta proposta cobre os dois, sob a marca do Pine.
| O que o documento exige | Como entra nesta proposta |
|---|---|
| C# .NET Core, SQL Server, RabbitMQ §4, Requisitos para Proposta | A orquestração assíncrona de validações que vive no perímetro do banco é escrita nesse padrão — a decisão de quem a escreve é do projeto. Os blocos são consumidos por API e não impõem linguagem a quem os chama; a mensageria do banco continua sendo a do banco. |
| Captura inteligente por CNPJ, com QSA | Bloco bureaus: 17 tipos de consulta implementados sobre CNPJ e CPF, com finalidade obrigatória por consulta e cache que impede pagar duas vezes pelo mesmo documento na mesma jornada. |
| Jornada stateful, pausar e retomar | O dossiê da empresa vive em data-store, salvo a cada passo; a retomada é por link, e-mail ou WhatsApp, sem senha para quem foi convidado. |
| OCR de contrato social e faturamento | data-extraction: o que extrair é um template em linguagem natural, e cada campo volta com nota de confiança — a mesa revisa só o que ficou abaixo do limiar. |
| Validação biométrica dos representantes legais | Bloco biometrics: sessão, página de captura hospedada com token de uso único e envelope de decisão com score, limiar e evidência com hash. |
| Assinatura com validade jurídica | e-signature com hash do documento e nível registrado (simples, avançada, qualificada); ICP-Brasil entra pelo bloco certificates se o compliance exigir. |
| Receita, Juntas Comerciais, Serasa/Boa Vista, antifraude | Um contrato único de consulta com provedores plugáveis. Receita e cadastral estão no ar; Juntas, Serasa/Boa Vista e antifraude entram como provedores novos atrás do mesmo contrato. |
| Analytics em todas as etapas, Dynatrace e Splunk | Evento por etapa emitido pelo próprio componente, e a trilha exportada para o SIEM do banco. |
| Conta criada no Core pelo API Gateway | Publicamos onboarding.approved com o dossiê assinado, por webhook com assinatura RSA e retentativa. Quem grava no core é o core. |
Um ponto que não está no documento e vale dizer em voz alta: Itaú e Santander, segundo a comunicação pública dos dois bancos, abrem conta PJ 100% online apenas para empresa de sócio único. A jornada proposta aqui trata quadro societário com vários sócios, procurador com alçada e holding no quadro — que é exatamente o perfil de empresa do Pine.
Hoje, num onboarding PJ típico, o apetite de aceitação vive em três lugares ao mesmo tempo: em condicionais dentro do código, numa planilha do compliance e na cabeça do analista experiente. As três versões divergem com o tempo, e mudar o apetite vira chamado, fila de desenvolvimento e release.
A proposta é outra: a política de aceitação é uma decisão versionada, escrita em tabela, publicada sem deploy, e cada abertura registra qual versão e qual linha decidiram. É o mesmo motor que hoje opera esteiras de crédito em produção — e, nesta entrega, ele fica habilitado para o Pine criar e manter as regras do onboarding.
A decisão continua sendo do banco, e a responsabilidade regulatória também — a Circular BCB 3.978/2020 aloca os procedimentos de conhecimento do cliente à instituição, não ao fornecedor de tecnologia. A plataforma não decide no lugar do Pine: ela executa a regra do Pine, guarda a prova e entrega a exceção para uma pessoa.
A separação é deliberada e é o que permite trocar fonte sem tocar na regra, e mudar a regra sem tocar na integração.
A restrição de stack do documento é respeitada onde ela importa: o que conversa com o API Gateway e com o Core é escrito no padrão da casa — C# .NET Core, SQL Server e RabbitMQ, como o §4 do documento de requisitos pede. Quem escreve essa camada é decisão de projeto: o time do banco, a SEMPRE IT como prime da integração, ou nós com parceiro. Para os blocos é indiferente — eles são chamados por HTTP com credencial de máquina e não impõem linguagem a quem os chama, do mesmo modo que o banco já consome bureau e assinatura hoje.
O catálogo tem 34 blocos. Doze compõem o Onboarding PJ, mais três que atravessam todos; os demais existem, estão documentados e ficam disponíveis por contrato — não fazem parte do escopo desta entrega. O estado de cada um é medido no código: no ar quando o bloco está em produção e já é usado por uma esteira real; parcial quando existe e falta uma peça nomeada; novo quando nasce aqui.
>= 18, "ativa". No Pine: a política de aceitação do onboarding, autorada pelo banco.onboarding.approved com o dossiê assinado, para o API Gateway criar a conta no core.open-finance (extrato e identidade bancária com consentimento) · calculations-engine (parcela, amortização, IOF e CET como API testada) · pricing-engine (taxa por faixa de risco, com tarifas e comissões no mesmo cálculo) · banking-product-portfolio · baas (contas, Pix e TED com provedor trocável) · ai-engine (IA sobre texto, imagem e áudio, na nuvem ou na rede do cliente) · calendar, email, commerce, payments, rooms, slack, sso, wpp e os demais. Citamos porque a resposta a “e depois?” é contratual e de configuração, não um novo projeto.
A mesa não é uma caixa de entrada. É a exceção da política, com prazo, alçada e devolutiva — e é onde o banco descobre que a regra precisa mudar.
| Peça | O que faz | Por que importa para o Pine |
|---|---|---|
| Fila | Só os casos que a política mandou para análise, com a coluna “na mesa porque” escrita em português a partir da linha que casou. | |
| Dossiê | Verificações com a fonte de cada uma, documentos lidos com confiança, pessoas e estado, o motivo exato e a ação sugerida. | A decisão é tomada numa tela só, sem abrir cinco sistemas. |
| Alçada | Quem aprova o quê e até quanto; individual, conjunta ou comitê, avaliada no servidor. | |
| Prazos | Varredura diária, prazo que pausa quando a bola está com o cliente e sobe de alçada quando vence. | O SLA do backoffice deixa de depender de alguém lembrar. |
| Devolutiva | Pedido de ajuste ao cliente com texto do analista, por e-mail e WhatsApp, retomando o passo exato. | |
| Auto de decisão | Exportação por caso, em JSON e em texto: a regra disparada, o fator que decidiu, a versão da política e a linha do tempo até o desembolso do processo. | É o documento que responde ao regulador e ao auditor interno sem trabalho manual. |
Não há um produto diferente por trás de cada projeto. Há um motor, um catálogo de blocos e um escopo habilitado — e é por isso que ampliar depois é contrato e configuração, não reimplantação.
| Motor ou superfície | Neste projeto — Onboarding PJ | Mesmo motor, outro módulo |
|---|---|---|
| Autoria de regras | Habilitada para o banco: tópicos, tabelas, versões, execução de versão em teste e publicação das regras de onboarding e aceitação cadastral. | Política de crédito, precificação por faixa de risco, régua de cobrança, alçadas operacionais. |
| Esteira de decisão | Fontes do onboarding: Receita, bureau, OCR e biometria. | |
| Mesa | Fila, dossiê, alçada, prazos, devolutiva e auto de decisão do onboarding. | Esteira de crédito completa: produtos, limites, instrumentos, formalização, carteira e provisão. |
| Blocos | Os 12 da jornada, com os provedores que o banco contratar. | |
| Agentes de IA | Fora do escopo. | Operação da mesa por conversa, com confirmação humana em toda mutação. |
| Hospedagem | Nuvem Catalisa ou infraestrutura do Pine: os blocos rodam em contêiner e o motor de IA já opera na rede do cliente. | Idem, por ambiente. |
A licença de uso da autoria de regras acompanha o domínio contratado. Isso não é uma trava técnica inventada para cobrar depois: é o mesmo desenho que permite ao banco começar pelo onboarding sem implantar uma plataforma de crédito inteira — e ampliar depois sobre a fundação já instalada.
Sem desviar o foco: nada abaixo faz parte do escopo desta entrega. Está aqui porque a arquitetura do onboarding é a fundação dos quatro — e porque a pergunta “e depois?” é legítima.
O mesmo par motor + mesa opera hoje, em produção, esteiras de originação a desembolso: produto, simulação, política, limite e folga, formalização com instrumento, desembolso, carteira, provisão por estágio e prévia de informe regulatório. Para o Pine, o custo marginal é o produto — a máquina já está de pé e a empresa já está cadastrada.
KYC não termina na abertura. A mesma esteira, disparada por tempo ou por evento, reconsulta bureau e listas, compara com o dossiê e só leva à mesa o que mudou. É o requisito de atualização cadastral resolvido com a regra que já existe.
O dossiê já produz quem opera, até quanto e sob qual regra de representação. O aplicativo desktop consome esse contrato em vez de reconstruir a mesma informação — é a razão pela qual o pilar (ii) e o pilar (iii) da proposta da SEMPRE IT se encaixam.
A mesma jornada, outro tipo de contraparte e outra tabela de aceitação. Trocar o público de análise é configuração de regra e de fonte, não um novo desenvolvimento.
| Caminho | Força | O que ele cobra em liberdade |
|---|---|---|
| Plataformas globais de decisão | Esteira completa, autoria visual madura e marketplace de dados. | |
| Bureaus que também vendem decisão | Profundidade de dado brasileiro difícil de igualar. | A decisão vem acoplada ao grupo que vende o dado — trocar de fonte passa a significar trocar de motor. |
| Construir na casa | Controle total e nenhuma licença. | |
| Catalisa | Motor com versionamento, publicação sem deploy e registro por execução já prontos; fontes plugáveis; blocos que rodam na infraestrutura do banco; backoffice como código do Pine; o time que escreve o código é o que atende — customização em dias, sem fila de roadmap. | Pede engajamento do compliance e do risco: a autoria da regra passa a ser do banco, e isso é uma mudança de rotina, não só de sistema. |
Nenhum dos três primeiros caminhos é ruim — são escolhas com preços diferentes em autonomia. A pergunta que resolve é simples: daqui a dois anos, quem o Pine quer que seja capaz de mudar a regra de aceitação sozinho?
Frente transversal do plano, da fundação ao go-live, com uma régua verificável: OWASP MASVS L2+R no aplicativo e ASVS L2/L3 nas APIs, além da Res. CMN 4.893/2021 e alterações posteriores (segurança cibernética e contratação de nuvem), da Res. CMN 4.753/2019 (abertura, manutenção e encerramento de conta de depósito), da Circ. BCB 3.978/2020 (PLD/FT) e da LGPD.
Regra que não abrimos: nenhum controle vive só no cliente. O aplicativo atesta e assina; alçada, limite e execução são decididos no servidor. Pentest externo fecha a fase de formalização, antes do go-live.
O documento de requisitos pede, com estas palavras, “mecanismos de log e auditoria para todas as transações corporativas” — e repete o pedido no documento do Desktop PJ. Propomos ir além do que foi pedido: não só transação, mas também acesso — quem abriu o dossiê de uma empresa, quem consultou o saldo, quem exportou uma lista de pessoas, quem entrou e quando saiu.
A razão é prática, não retórica: numa instituição financeira, a pergunta do auditor e a do time de fraude quase nunca é “o que aconteceu?” — é “quem viu?”. E o padrão que denuncia vazamento ou uso indevido é acesso anômalo (um usuário abrindo duzentos dossiês numa madrugada), não transação anômala.
Auditar toda leitura multiplica o volume por uma ordem de grandeza: num internet banking, consulta é a esmagadora maioria do tráfego. Registrar tudo no mesmo balde produz uma trilha onde ninguém acha nada, e um custo de retenção que ninguém quer pagar. Por isso propomos quatro classes, com destino e retenção próprios — o banco define os prazos; a classificação é nossa entrega.
| Classe | Exemplos | Onde vive | Por que separada |
|---|---|---|---|
| Ato de negócio | Ordem emitida e aprovada, alçada aplicada, decisão da política, publicação de versão, abertura aprovada ou recusada, mudança de usuário e de limite. | Trilha imutável, retenção longa. | É prova. Precisa sobreviver e não pode ser alterada depois de escrita. |
| Acesso a dado | Abrir o dossiê de uma empresa, ver saldo e extrato, listar sócios, baixar documento, exportar relatório, consultar bureau — esta com finalidade obrigatória. | Trilha, retenção média. | Responde “quem viu o quê” — a LGPD trata consulta como operação de tratamento, e é aqui que vazamento aparece. |
| Sessão e identidade | Entrada e saída, segundo fator, falha de autenticação, dispositivo novo, elevação de privilégio, revogação de acesso. | Trilha de segurança, alimenta a detecção no SIEM. | É o material de investigação de incidente e a base das regras de alerta. |
| Navegação e telemetria | Tela aberta, tempo de resposta, erro de front, funil de etapa. | Log de aplicação no Dynatrace e no Splunk, retenção curta, sem dado pessoal. | Serve a produto e a operação, não a auditoria — e é o volume que não pode contaminar as três classes acima. |
| Onde o ato acontece | O que fica registrado | Quem consulta, e como |
|---|---|---|
| Jornada do cliente | Cada passo salvo, com data e canal; consentimento aceito; documento enviado, com quem enviou e o resultado da leitura; convite gerado para cada sócio e o que ele fez no celular. | Backoffice, na linha do tempo da empresa. Serve para responder “por que essa abertura demorou”. |
| Consulta a dado de terceiro | Quem consultou, qual documento, qual finalidade — campo obrigatório, sem valor padrão — e se veio do cache ou do fornecedor. O documento consultado nunca é gravado em claro. | Exigência de LGPD atendida por desenho: a base legal de cada consulta fica registrada, não declarada. |
| Decisão | Entrada, entrada enriquecida pelas fontes, saída, tempo de execução, qual versão da política e quem executou — uma linha por execução, com o erro guardado quando houve. | Auto de decisão por caso, em JSON e em texto. É o documento que responde ao regulador. |
| Mesa e backoffice | Quem abriu cada dossiê e o que exportou; quem aprovou, recusou ou devolveu, sob qual alçada, com a observação escrita pelo analista; prazo aberto, pausado e cumprido; publicação de versão da política, com data. | Backoffice e exportação. É o que sustenta a segregação de funções na auditoria interna. |
| Aplicativo PJ | Entrada e saída, segundo fator e dispositivo; consulta de saldo, extrato e comprovante, com quem consultou; ordem emitida e por quem; assinaturas que faltavam e quem completou; alçada aplicada no servidor; mudança de cadastro de usuário e de limite. | Trilha do banco e aviso por outro canal a quem não emitiu a ordem. |
| Integração com o core | Evento publicado, assinatura, tentativas de entrega e resposta recebida — o histórico completo, não só a última tentativa. | Histórico de entrega, consultável quando o core reclamar de algo que não chegou. |
Duas perguntas que um banco faz antes de assinar: o que acontece quando uma peça cai, e o que acontece quando o banco decide internalizar. As duas têm resposta arquitetural nesta proposta, não resposta comercial.
Nenhuma peça desta arquitetura é um nó cego. Cada uma é um contrato — HTTP, com credencial de máquina e formato estável. Substituir uma peça por um sistema do próprio Pine significa implementar aquele contrato; o resto da jornada não fica sabendo. Isso não é uma concessão de última hora: é a razão de os blocos serem blocos.
| Peça | Como o banco internaliza | Impacto no resto do desenho |
|---|---|---|
| Consulta cadastral | Registra o próprio fornecedor como provedor do bloco, ou expõe o serviço interno no mesmo contrato de consulta. | Nenhum. A esteira continua chamando o mesmo endereço, com a mesma finalidade registrada. |
| Biometria | Pluga o fornecedor que o banco já tem; o envelope de decisão — score, limiar, evidência — continua o mesmo. | Nenhum. A política lê o resultado, não o fornecedor. |
| Assinatura | Provedor por organização, ou a plataforma de assinatura do próprio banco assumindo o envelope. | Nenhum. Hash e nível seguem registrados do mesmo jeito. |
| Motor de decisão | As políticas são DMN, padrão aberto da OMG: o XML é exportável e executa em qualquer runner compatível. | A regra é portável. O que não vai junto é o que construímos em volta — versionamento, registro por execução e isolamento por organização. |
| Dossiê e estado | Exportação das coleções em JSON, ou apontar a jornada para a base do banco. | Nenhum na jornada: a leitura e a escrita são pela mesma API. |
| Trilha | Exportada continuamente para o SIEM do banco; o auto de decisão sai em JSON por caso. | Nenhum. O banco já tem a cópia enquanto o sistema opera. |
| Backoffice | Já nasce assim: código do Pine, no repositório do Pine. | Nenhum. Nunca esteve do nosso lado. |
| Entrega ao core | Webhook assinado, ou publicação numa fila do próprio banco. | Nenhum. O evento é o mesmo contrato. |
A ordem abaixo é técnica: cada etapa existe porque a seguinte depende dela, e nenhuma é declarada pronta por relatório — fecha com uma prova que roda em homologação do Pine.
| Etapa | Entrega | Prova que a fecha |
|---|---|---|
| 1 · Fundação | Pessoa jurídica no cadastro; biometria com provedor real; provedores de Juntas, Serasa/Boa Vista e antifraude; conector de OCR; orquestração no padrão do banco. | Um CNPJ atravessa da consulta à decisão, ponta a ponta, em homologação. |
| 2 · Jornada | Captação e formalização sob o design system do Pine, multi-sócio, convite por pessoa, regra de representação, holding até o beneficiário final. | Uma empresa com três sócios conclui sozinha, em homologação. |
| 3 · Decisão e mesa | Política autorada pelo banco, simulação, publicação; backoffice como código do Pine, com fila, dossiê, alçada, prazos e auto de decisão. | O compliance publica uma versão e um caso muda de resultado sem deploy. |
| 4 · Formalização e core | Ficha e termos por template, assinatura com evidência, evento assinado para o API Gateway. | Conta aberta ponta a ponta, com o dossiê no core. |
| 5 · Observabilidade | Trilha exportada, logs em Dynatrace e Splunk, funil por etapa, regras de detecção. | Go-live com painel de funil e alerta ativos. |
| T · Segurança | Frente transversal: atestação, assinatura de transação, pinning e mTLS, upload hostil, trilha imutável, SSDLC com SBOM. | Pentest externo antes do go-live, com re-teste. |
As etapas 1 e 2 são independentes entre si e correm em paralelo. A frente de segurança atravessa todas, da fundação ao go-live.