Virtual Entitlements
A virtual Entitlement is a Role a User holds because their USER_ID is listed in an instance props entry, not because an Entitlement row exists.
Two props entries grant them:
super_admin_user_ids: CanCreateEntitlementAtOneBank, CanCreateEntitlementAtAnyBank, CanGetAnyUseroidc_operator_user_ids: CanGetAnyUser, CanVerifyUserCredentials, CanVerifyOidcClient, CanGetOidcClient, CanGetOidcConsent, CanGetConsumers, CanCreateConsumer
Where they appear: GET /my/entitlements and GET /users/current list them next to stored Entitlements with an empty entitlement_id and an empty bank_id; in v6.0.0 and later created_by_process names the props entry.
What they do: a virtual Entitlement satisfies the Role check of a direct call exactly as a stored one would. Super admins additionally bypass the granting-Role check of Add Entitlement, so they can grant any Role to any User (including themselves) at any Bank.
What they do not do: they are not rows, so they cannot be deleted or listed per Bank, and they cannot be delegated. A Consent may only carry stored Entitlements of the User creating it, so a super admin who wants an agent (a consent user) to hold a Role must first grant that Role to their own USER_ID with Add Entitlement, then create the Consent that carries it. The "just in time" grant (create_just_in_time_entitlements) likewise honours only stored granting Roles.
See also Roles of Open Bank Project and Consent.