DEV Community: Viktoriia Mykhalchuk

RBAC Isn’t a Checkbox: Why Permission Structures Are Getting Regulatory Attention

Viktoriia Mykhalchuk — Thu, 15 Oct 2026 09:55:57 +0000

Role-based access control in fintech determines who can view customer data, approve payments, and change platform settings. As regulatory expectations place greater emphasis on access governance, financial institutions need permission structures that reflect real responsibilities, prevent conflicting duties, and leave a clear record of sensitive actions.

A support employee needs to investigate a delayed payment. Someone grants administrator access so they can resolve the issue quickly. The investigation ends, but the permissions remain.

Months later, that account can still change customer details, approve transactions, and manage other users. No security control necessarily failed at login. The problem is what the authenticated user was allowed to do.

For financial platforms, role-based access control, or RBAC, determines how operational responsibility becomes enforceable permission. A system with only “admin” and “user” roles may be easy to launch, but it can leave sensitive actions concentrated in too few hands.

Regulatory attention makes those boundaries harder to treat as an implementation detail. DORA provides explicit requirements concerning access rights and segregation of duties. The PSD3 and PSR reform adds a broader governance and payment-security context, although its status must be distinguished from requirements already applicable.

What RBAC in Fintech Actually Controls

RBAC assigns permissions through defined roles. In a financial platform, those permissions should reflect specific responsibilities across customer support, compliance, finance, and administration.

The important distinction is often between actions on the same record.

A support employee might need to view a transaction without approving it. A compliance analyst may need to investigate or reject a suspicious payment without changing platform settings. A finance user may need to release eligible transactions without altering risk controls.

Giving each team a different role name is only the beginning. The underlying permissions must create meaningful boundaries.

A useful assessment starts with three questions:

Which information does this person need to see?
Which actions must they perform?
Which combinations of actions would let th em bypass a control?

The third question is where segregation of duties becomes essential.

DORA Makes Segregation of Duties Explicit

DORA has applied since January 17, 2025. For financial entities within its scope, access governance forms part of the operational resilience framework.

Article 21 of Commission Delegated Regulation (EU) 2024/1774 specifies access-control requirements under the full ICT risk management framework. These include permissions based on need-to-know, need-to-use, and least privilege, alongside segregation of duties intended to prevent combinations of rights that could circumvent controls. It also addresses user accountability and access management. Entities subject to the simplified framework must assess the provisions applicable to them.

This does not mean the regulation prescribes a universal set of software roles called “Support,” “Compliance,” and “Finance.” It establishes control objectives that institutions must translate into their own operating model.

The practical implication is clear: a permission structure should be explainable in terms of business responsibilities and risks.

If someone can change a control, execute the affected operation, and conceal the evidence, the existence of an RBAC module offers little reassurance.

How PSD3 Fits Into Access Governance

PSD3 should be discussed separately from DORA’s existing access-control requirements.

The European Parliament’s legislative tracker, updated on August 1, 2026, records a provisional agreement on PSD3 and PSR and committee approval of the negotiated text. It also states that formal adoption is required before entry into force. PSD3 focuses on the authorisation and supervision of payment institutions, while the wider package addresses payment security and other payment-services rules.

For product planning, the relevant connection is governance readiness. Institutions preparing for the revised payments framework benefit from being able to demonstrate who controls sensitive processes and how those controls operate.

However, “PSD3 requires this exact RBAC configuration today” would overstate the position. The explicit access-control basis discussed here comes from DORA’s technical standards.

Segregation of Duties Requires More Than Separate Role Names

Segregation of duties prevents incompatible responsibilities from being concentrated in one person or access path.

Consider a hypothetical supplier-payment workflow. One employee can update bank details, approve the change, and release the first payment to the new account. Each permission may seem reasonable in isolation. Together, they remove independent scrutiny.

A more controlled design separates those steps.

- Beneficiary changes: Editing bank details and approving the same change creates a risky permission combination. Evaluate independent approval of sensitive amendments.
- Manual payment review: Creating and approving the same payment removes independent scrutiny. Evaluate separate initiation and approval.
- Risk configuration: Changing a rule and releasing affected transactions combines configuration authority with operational approval. Evaluate separating those responsibilities.
- Administrator management: Granting oneself unrestricted access creates a risk of unchecked privilege escalation. Evaluate controlled privilege changes with independent oversight.
- Audit evidence: Performing sensitive actions and altering their records compromises accountability. Evaluate protected logs and restricted log administration.

These are design examples, not a universal regulatory permission matrix.

RBAC also does not automatically enforce every form of separation. A role may permit payment approval while a separate workflow rule prevents the user from approving their own payment. Both controls need to work together.

Why Deny-by-Default Matters

Deny-by-default means access remains unavailable unless it has been explicitly granted.

This is particularly useful as platforms grow. When a new export, configuration screen, or transaction action is introduced, users should not inherit access simply because nobody added a restriction.

OWASP recommends denying access by default and validating permissions on every request. These principles support consistent authorisation across the application.

For a fintech team, this changes the permission-design question from “Who should we block?” to “Who has a justified reason to perform this action?”

The distinction matters during product releases. A new feature should arrive with a defined permission owner and an explicit access decision.

A Hidden Button Is Not an Access Boundary

Removing a button from the interface can make the workspace clearer. The operation must still be protected when requested directly.

Authorisation should be enforced where the action is executed, including API requests and relevant resource checks. A user who cannot see another customer’s account in the interface should not be able to retrieve it by changing an identifier.

Roles may therefore need additional restrictions based on the organisation, account, transaction, or workflow state. RBAC provides a foundation, but the full permission decision can require more context.

What Operational RBAC Looks Like

Finhost’s Role-Based Access Control (RBAC) functionality uses defined Back Office roles for Admin, Compliance, Support, Finance, and Sales, alongside a protected Owner role. Each administrator receives one role, and actions outside that role remain restricted by default.

Its documented model separates responsibilities such as compliance review and rejection from financial approval. This gives teams a concrete basis for allocating operational access.

The institution still needs to assess whether those boundaries fit its own workflows. Role assignment should follow actual responsibilities rather than seniority or convenience.

Broad Owner or administrator access also needs explicit governance. Organisations should determine who holds it, how it is protected, and how its use is reviewed.

Audit Trails Show Whether Permission Controls Worked

An access policy explains what someone was permitted to do. An audit trail shows what they actually did.

Both are needed to investigate a sensitive operation. A reviewer may need to establish who changed a record, which account was affected, what changed, and what happened next.

Finhost’s full audit trail & activity logs brings Back Office and customer activity into a searchable Logs center. Its documented functionality includes separate actor and target fields, before-and-after values for changes, filtering, and CSV exports, with append-only, non-editable records.

These capabilities support investigation and review. Institutions should still confirm event coverage, retention periods, and access to exported evidence for their implementation.

Logs do not compensate for excessive permissions. Discovering an inappropriate action afterwards is different from preventing it. Their value increases when they support regular oversight as well as incident investigation.

How to Assess a Fintech Provider’s Permission Model

When evaluating a white label fintech solutions provider, ask for a demonstration of permission boundaries using realistic operational scenarios.

A useful review should establish:

- Action-level separation: Can viewing, editing, exporting, approving, and administering be controlled appropriately?
- Workflow separation: Can the system prevent the same person from completing incompatible steps?
- Consistent enforcement: Do restrictions apply beyond the visible interface?
- Access lifecycle: What happens when someone changes roles, leaves, or no longer needs elevated access?
- Evidence: Can reviewers reconstruct sensitive actions and permission changes?
- Privileged access: How are broad administrative rights protected and supervised?

A demonstration is more informative than a feature-list checkbox. Ask to see a restricted user attempt an action and then inspect the resulting record.

Build Permissions Around Decisions, Not Convenience

A practical RBAC review starts with sensitive decisions: releasing money, changing recipient details, modifying risk settings, granting access, and exporting customer data.

Map who needs each action, identify combinations that defeat independent control, and verify that restrictions work across the complete workflow. Then review access as people, responsibilities, and products change.

Deny-by-default keeps unapproved access closed. Segregation of duties limits incompatible authority. Audit trails make actions reviewable.

Together, these controls turn a set of role names into a permission structure that a financial institution can explain, test, and govern.

The EU’s Zero-Threshold Crypto Travel Rule: What Small Transfers Require

Viktoriia Mykhalchuk — Thu, 15 Oct 2026 09:40:05 +0000

A customer withdraws €50 worth of crypto. The amount is small. The platform still needs to handle the required sender and recipient information.

Under the EU’s revised Transfer of Funds Regulation, covered crypto transfers have no general minimum-value exemption from Travel Rule information requirements. A transfer below €1,000 remains within those requirements. Council of the EU’s explanation of the rules.

For crypto platforms, that changes where compliance belongs in the product. Information collection, counterparty identification and exception handling need to work throughout the everyday deposit and withdrawal journey.

The implementation question is straightforward: can the platform process a small transfer with the required information and a clear record of the decision?

What the EU’s zero-threshold Travel Rule covers

The crypto provisions of Regulation (EU) 2023/1113 have applied since 30 December 2024. They cover transfers where the originator’s or beneficiary’s crypto-asset service provider, including an intermediary, is registered in the EU.

Direct person-to-person transfers without a crypto-asset service provider are excluded. A transfer between a regulated platform and a self-hosted address is a different case.

Required information must be submitted securely before or alongside the transfer. It does not need to be written onto the blockchain itself. Transfer of Funds Regulation, Articles 2, 14 and 40.

This distinction matters for platform architecture. Asset movement and information exchange may use separate technical channels, but their records need to remain connected.

A transaction hash establishes that an on-chain transaction occurred. The platform also needs evidence that the accompanying information was handled correctly.

Why the FATF $1,000 threshold causes confusion

FATF’s guidance allows jurisdictions to adopt a USD/EUR 1,000 de minimis threshold for virtual asset transfers. Below that threshold, fewer requirements may apply.

Even then, the guidance calls for providers to collect the originator’s and beneficiary’s names, together with their wallet addresses or a unique transaction reference. Customer information should be verified where suspicious money laundering or terrorist financing circumstances arise. FATF guidance, paragraphs 191–192.

Describing this as a blanket “$1,000 exemption” can lead to incorrect product logic.

A team might build a withdrawal flow that starts collecting counterparty information only after the amount reaches $1,000. That design would leave a gap for EU-covered transfers.

For a platform operating across markets, the applicable jurisdiction should determine the information workflow. A generic threshold in a vendor’s example configuration cannot establish the legal requirements for every deployment.

Why €1,000 still matters for self-hosted wallets

The EU’s zero-threshold approach does not remove every monetary distinction.

For transfers exceeding €1,000 to or from a self-hosted address, the relevant provider must take adequate measures to assess whether that address is owned or controlled by its own customer. This assessment is additional to the underlying transfer information requirements. Transfer of Funds Regulation, Articles 14(5) and 16(2).

Product teams should keep these decisions separate:

Applicable information requirements: What information is required for this transfer?
Wallet classification: Is the address hosted by a provider or self-hosted?
Ownership or control assessment: What evidence is needed about the customer’s relationship with the address?
Transaction risk review: Do the available findings require further action?

A platform also needs a correction path. An address that is not recognised as belonging to a provider may still be hosted.

Finhost’s unhosted wallets management documents ownership-related checks and lets customers identify the actual provider when a wallet has been classified incorrectly. The service requires separate enablement, and the verification method needs to fit the deployment’s requirements.

A completed wallet check supplies evidence about the address relationship. Transaction risk still requires its own assessment.

Travel Rule legislation reached 83% of surveyed jurisdictions

The EU operates within a growing international framework.

In its 16 July 2026 targeted update, FATF reported that 83% of surveyed jurisdictions had passed legislation implementing the Travel Rule, up from 73% in 2025. That represents an increase of ten percentage points. A further 11 jurisdictions reported that implementation was under way. FATF’s July 2026 targeted update.

These figures measure legislative adoption. They do not establish how many providers exchange complete information successfully or how many transfers meet the requirements in practice.

FATF also highlighted continuing gaps in supervision and enforcement.

For platform teams, the operational implication is to assess actual counterparty readiness. A provider may operate in a jurisdiction with Travel Rule legislation while using different messaging infrastructure or handling information requests inconsistently.

Counterparty testing should therefore cover successful exchanges, unavailable connections, incomplete responses and follow-up procedures.

Build the information workflow into ordinary transfers

A useful implementation starts when the customer creates the transfer.

The platform should identify the relevant counterparty, determine what information is needed and check which details are already available. Customers should receive a focused request for anything outstanding.

Finhost’s crypto travel rule compliance describes transfer outcomes including approved, requires action, on hold and failed. Its documented workflow connects customer information requests and compliance review to the transaction.

For an EU deployment, teams should validate that the configured workflow applies the required information checks to covered transfers of every value. Finhost’s published page includes FATF threshold examples; those examples should not be treated as the EU rule.

The acceptance test should include small amounts from the start. A €50 withdrawal is a useful case because it exposes any logic that incorrectly bypasses information requirements below a monetary threshold.

Make missing information and technical failures distinguishable

Consider a €75 withdrawal to another crypto platform. The customer provides the recipient’s name, but the receiving provider cannot be reached through the configured messaging service.

Asking the customer to enter the same name again will not resolve the connection problem.

The platform needs to identify the reason the transfer cannot progress and direct the case to the appropriate next step.

Customer information is missing: Make clear which details are required and how to submit them.
Counterparty connection is unavailable: Identify which team owns the investigation and follow-up.
Received information is incomplete: Specify what needs clarification from the counterparty.
Wallet classification is uncertain: Explain how the customer or reviewer can correct it.
A risk finding requires review: Identify who will assess the case and record the outcome.

These are implementation recommendations. The decision to execute, suspend, reject or otherwise resolve a transfer must follow the applicable requirements and the operator’s approved procedures.

Retries also need to remain linked to the original case. Otherwise, staff may see several requests without being able to establish which response belongs to the transfer.

Treat blockchain receipt and customer availability separately

Incoming transfers create a different operational challenge: assets may arrive on-chain while information checks remain unresolved.

A single “completed” status can hide that distinction.

The internal record should let staff identify whether assets have been received, whether required information is complete and whether the funds are available to the customer.

The customer-facing explanation should reflect the actual state. If information is missing, the customer needs a clear request. If the case is under review, support needs an accurate explanation of what is happening.

A practical test is to send an incoming transfer with incomplete information and ask:

Can the reviewer identify exactly what is missing?
Is there a defined follow-up process?
Can support explain the status accurately?
Is the release decision recorded?
Can the team reconstruct the full sequence afterwards?

Connect Travel Rule checks with transaction monitoring

Travel Rule information and transaction monitoring contribute different evidence.

The information workflow establishes details about the parties to a transfer. Monitoring assesses activity and risk. Complete sender and recipient details do not resolve a suspicious transaction, and a favourable screening result does not supply missing information.

Teams evaluating Finhost’s AML & Transaction Monitoring (KYT) should review how screening outcomes connect with Travel Rule cases and the execution process.

For example, a transfer may have complete counterparty information but require compliance review because of a risk finding. Another may have no identified risk signal while still awaiting mandatory details.

Both need an understandable status, an assigned next action and a recorded decision.

For reviewers, the aim is a transaction record that brings the relevant evidence together. For customers, it is a clear explanation of what happens next.

What crypto platforms should review now

Start with every rule that uses transaction value to activate or bypass information checks.

Then test the main paths separately: a small provider-to-provider withdrawal, a self-hosted wallet transfer, an incoming deposit with missing information and an unreachable counterparty.
For each case, establish:

Which jurisdictional requirements apply.
What information and verification evidence are required.
Which enabled service or integration handles each step.
Who resolves exceptions.
What record supports the final decision.

Once the workflow is operating, measure how often transfers need customer action, how long cases remain unresolved and which counterparties create repeated exceptions. Those measures help teams identify where the product needs clearer requests, better connectivity or more review capacity.

The EU’s zero-threshold Travel Rule makes small transfers part of the same operational responsibility. A working implementation connects the required information, the movement of assets and the evidence behind the decision—even when the customer is sending only €50.