How should identity teams implement Open Banking Brazil compliance when the authorization server is already close but not fully complete?

Treat the identity server as only part of the control plane. Map the remaining regulatory gaps, then place the missing validation and registration checks in a fronting integration layer or API gateway. That approach lets teams meet OBB requirements now while the product closes JAR, PAR, encrypted request object, and JARM support in later releases.

How to close the remaining Open Banking Brazil compliance gap without waiting for the core server

The practical move is to separate the compliance decision from the product completion path. If the authorization server is already doing most of the work, identity teams can front the remaining OBB checks in an integration layer that validates registration, request structure, and required security signals before traffic reaches the server. That keeps delivery moving while the platform team finishes the remaining protocol features.

For practitioners, this works best when the fronting layer is treated as part of the regulated control plane, not as a temporary hack. It should be capable of rejecting non-conforming requests, enforcing policy consistently, and producing evidence that the missing controls are being applied at the point of entry.

What the control split should look like in practice

The split is usually between identity and protocol enforcement. The authorization server remains responsible for authenticating the authorization flow and issuing the result, while the fronting layer handles the checks the current product cannot yet guarantee on its own. In Open Banking terms, that often means validating the presence and shape of the request, ensuring the registration state is acceptable, and enforcing any compensating checks needed for secure processing.

This pattern is especially useful when features such as JAR, PAR, encrypted request objects, or JARM are close to complete but not yet ready for production. The gap should not be hand-waved away. It should be mapped explicitly so each missing control is either enforced upstream, deferred behind a documented exception, or scheduled into the next release with clear ownership.

For teams already managing broader identity and access controls, this is the same discipline that applies to any partially mature control plane. NHIMG’s IAM and IGA Basics is useful for the underlying governance model, while the Regulatory and Audit Perspectives section helps frame how compensating controls become auditable obligations rather than ad hoc workarounds.

Which gaps matter most before go-live

The first priority is to identify which missing OBB capabilities create real exposure if the server is exposed directly. If a request object can be altered in transit, if request delivery is not yet protected by a pushed authorization pattern, or if response integrity is not yet bound tightly enough for the relying party, those are not cosmetic gaps. They are the points where client intent, authorization integrity, and replay resistance can weaken.

The second priority is lifecycle control around the temporary layer itself. A fronting gateway or integration service only helps if its ruleset is versioned, monitored, and retired when the native server support is ready. Otherwise the compensating control becomes a permanent parallel path, which is how teams end up with two overlapping policy engines and no clear source of truth.

For a deeper lifecycle and governance lens, NHIMG’s NHI Lifecycle Management Guide gives a useful model for how to treat transitional controls as managed assets, and the Lifecycle Processes for Managing NHIs section reinforces the need to plan for decommissioning as part of deployment, not after the fact.

Risk and Threat Considerations

When compliance is implemented through a fronting layer, the main risk is false confidence. The organisation may believe the authorization server is “effectively compliant” when the real protection lives elsewhere, and that can create weak boundaries, inconsistent enforcement, or gaps when traffic bypasses the proxy path.

Failure mechanism: Requests that should be validated or wrapped in stronger protocol protections can reach the core server through an unprotected route, or the compensating layer can be applied inconsistently across clients, tenants, or environments.

Impact: Authentication and request integrity can degrade, audit evidence becomes harder to defend, and a partial implementation can turn into an exposure if the temporary control is not enforced everywhere the regulated flow exists.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Authorization-server assurance depends on strong subject authentication in the flow.
	IA-5 — Authenticator Management	Temporary compensating controls still depend on safe credential and secret handling.
	AC-6 — Least Privilege	The fronting layer should only enforce the minimum permissions needed for OBB checks.
Recommendation — Enforce strong authentication for the identities operating the Open Banking flow. Manage and rotate the credentials used by the interim control layer. Restrict the compensating layer to the minimum access needed to validate OBB requests.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	OBB gaps around encrypted request objects directly touch cryptographic handling.
	A.8.20 — Network security	A fronting integration layer or API gateway is a network-enforced control point.
Recommendation — Apply cryptographic controls where OBB request integrity and confidentiality depend on them. Harden the gateway path that sits in front of the authorization server.

Practitioner Guidance

What to prioritise: Put the missing regulatory checks into the fronting layer first, but only for the specific controls the current server cannot yet enforce natively. Keep the scope narrow so the temporary layer is easy to test, prove, and remove.

What to verify: Confirm that every regulated path actually traverses the compensating layer, that rejected requests fail closed, and that logs show enough detail to demonstrate which rule blocked the request and why.

Decision rule: If a missing OBB control affects request authenticity, integrity, or registration validity, treat it as a go-live blocker unless an upstream control can enforce the same outcome with equivalent assurance.

Practitioner takeaway: The safest interim design is the one that turns “almost compliant” into a clearly bounded, observable control stack, while making the removal of the temporary layer a tracked delivery milestone rather than an informal future intention.