BCB Resolution and email security for Brazilian fintechs

Brazilian fintechs and authorized payment institutions live under BCB Resolução 4.893/2021 and its complementary normatives. The text talks about cybersecurity policy, third-party risk, and incident management in fairly broad strokes — but the supervisory expectations land on familiar controls: identity, integrity, availability, and the ability to demonstrate them.

Email domain integrity sits inside that “integrity” pillar, and DMARC is the standard implementation.

What BCB inspectors ask

In practice, supervisory teams ask three questions:

1. What domains do you own that are used to communicate with customers? Most fintechs underestimate this — every campaign subdomain, every transactional sender — and miss DMARC on the long tail.
2. What is your DMARC policy on each domain? p=none is treated as “configured but not enforced.” Inspectors will note the gap.
3. How do you know the policy is working? RUA reports, classified by source. Without aggregation, “I have DMARC” is a paperwork claim, not a control demonstration.

The cyber-resilience angle

Fraud-driven phishing typically targets the institution’s primary domain to extract authentication factors or to drive social-engineering schemes. The BCB framework leans on operational resilience — preventing the incident is far cheaper than the incident-response and customer-communication cycle that follows.

A pragmatic ramp

For a regulated fintech with a single-digit security team:

• Inventory every domain that sends mail (transactional, marketing, support).
• Publish p=none on each, with RUA pointed at one inbox.
• Aggregate the reports; classify the sources.
• Lift to p=quarantine per domain once the source list is clean.
• Monthly: snapshot the policy and evidence. File it under “operational risk” controls.

This is the path Atalaia exists to make boring. The controls are the same; the evidence problem is the same; the difference is whether you spend a day a month on it or six.