Identity Wallets Are Data-Sharing Layers

A wallet presentation can verify technically while still failing if source, purpose, identifier use and remedy are not governed.

Why high-assurance wallets need lawful reliance, sole control, post-presentation verification and identifier governance

World Bank paper on digital ID wallets and verifiable credentials gives governments, donors and implementation teams a useful entry point into identity wallets, attestations, trust frameworks and deployment choices. It explains the machinery clearly enough for readers who need to understand how wallets, issuers, holders, verifiers and authoritative sources fit together.

That is the value of the paper.

The gap appears when the same explanation is tested against high-assurance use cases. KYC, onboarding, eligibility, permits, payments and regulated access do not only require an attestation to move from one actor to another. They require the resulting reliance event to be lawful, attributable, auditable, correctable and subject to remedy.

The paper starts from the movement toward decentralized architectures, where trust and verification are shared across several actors. That is a common way to describe wallet ecosystems. It is not the best starting point for public or regulated services where consequences follow from the wallet transaction.

A wallet is not trusted because the architecture is decentralised. It is trusted only when legal authority before technical exchange, institutional mandate, authentic source, reliance, evidence and remedy are in place.

This is where the attestations (credential) paradigm becomes too small. Issuance, storage, presentation and verification describe the movement of an attestation. They do not describe the public or regulated act that follows from it.

An identity wallet is not simply a container for attestations. It is a governed data-sharing layer. It is the place where identity-linked data is selected, disclosed, accepted, matched, relied upon, recorded and later challenged. The attestation is the payload. The wallet-mediated exchange is the event that may trigger a decision.

That distinction matters because technical success can hide institutional weakness. A presentation can verify cryptographically and still fail as trusted public infrastructure. The relying party may have no mandate to request the data. The authentic source may not be established. The issuer may not be authorised for the purpose. The shared identifier may be used outside its proper context. The user may have no practical path to correction, erasure, review or remedy.

The next wallet debate should therefore not be about whether attestations can be issued and verified. That part is necessary, but it is not sufficient. The real question is whether wallet-mediated data sharing can support lawful, high-assurance reliance under sole user control.

That requires a different test: legal authority before technical exchange, institutional mandate before ecosystem participation, authentic sources before attestations, post-presentation verification before reliance, consent lifecycle management before reuse, identifier governance before matching, and remedy before scale.

The paper explains attestations, but not reliance

A useful technical model can still be too small for governance.

The World Bank paper explains the familiar wallet flow through three actors: issuer, holder and verifier. In that model, the issuer creates and signs an attestation, the holder stores and presents it, and the verifier checks whether the presentation is valid.

For introductory purposes, that model works. For high-assurance reliance, it stops too early.

The paper says that attestations (verifiable credentials) can be verified by third parties without needing to contact the issuer. That may be true for parts of the technical validation process. It does not answer the harder question: whether the relying party may lawfully rely on the disclosed data for the decision it is about to make.

This is the difference between verification and reliance.

Verification asks whether the attestation is technically valid. Reliance asks whether a named actor may use that disclosure for a defined purpose, under an accountable mandate, with an auditable record and an operable remedy path.

The distinction becomes important as soon as the wallet is used for KYC, onboarding, eligibility checks, permits, payments or regulated access. In those settings, the verifier is not merely a technical checker. It is a relying party. It asks for data, receives data, validates data, stores data, matches data, and may trigger a decision that affects access, rights, obligations or risk treatment.

An attestation may verify technically while the reliance event remains defective. The relying party may not be authorised to request the data. The purpose may be too broad. The authentic source may not be properly established. The issuer may have authority to issue the attestation, but not for the specific use case. The status may be stale. The user may have no effective route to correction or review.

That is why the issuer–holder–verifier model does not carry the whole governance burden. It describes movement. It does not describe authority.

A trust framework cannot stop at signature verification, schemas, keys and status lists. It must answer a more demanding chain of questions: who is entitled to request the data, which authentic source supports it, which issuer is authorised, what identifier is used for matching, what the relying party may retain, how the decision is evidenced, and how the person can challenge the result.

The paper gets the attestation flow broadly right. What it does not yet provide is the cross-match gate needed before a wallet presentation can become trusted public or regulated infrastructure: legal authority, institutional mandate, authentic source, governed service logic, execution evidence, public interface rights and oversight with remedy.

Without that gate, a wallet presentation can be technically successful but institutionally weak. It can prove that something was signed, while failing to prove that the resulting decision was lawful, necessary, attributable, correctable and reviewable.

The wallet is a governed data-sharing layer

The paper’s wallet definition is deliberately simple. It calls the wallet a software container that allows users to receive, hold and share digital credentials.

That is useful as a first explanation. It is too limited for public infrastructure.

A wallet is not only a place where attestations sit. It is the user-side layer through which identity-linked data moves from an authentic source, through an authorised issuer, to a relying party that wants to act on it.

That makes the wallet a governed data-sharing layer, not merely a container. It is where data is selected, disclosed, transmitted, accepted, matched, retained, challenged and sometimes reused. Those actions are not neutral technical steps. They are governance events.

The World Bank paper recognises this only indirectly. It says wallet implementation should consider how the wallet will interact with data-sharing systems, payments and authentication layers. That is important, but the relationship should be stronger. The wallet does not merely interact with data sharing. For high-assurance identity use cases, the wallet is one of the places where governed sharing happens.

This changes the procurement question.

A procurement team should not ask only whether the wallet can issue, store and present attestations. It should ask whether the wallet-mediated exchange is authorised, purpose-bound, visible to the user, under the sole control of the user, technically constrained, recorded as evidence, and linked to correction or remedy when something goes wrong.

The plumbing does not grant access lesson is the same. A platform may connect institutions, but it does not create entitlement to receive data. A wallet may present an attestation, but it does not itself create a lawful right to rely on it.

That right must come from the legal and institutional chain behind the exchange: the authentic source, the issuer mandate, the relying-party purpose, the identifier strategy, the status and revocation rules, the audit trail, and the remedy route.

The wallet should therefore be analysed as infrastructure between layers, not as a product at the edge. It sits between records and decisions. It carries assertions from one context into another. It enables disclosure, but it also creates risk: over-requesting, silent matching, identifier reuse, stale reliance, excessive retention and weak contestability.

For high-assurance use cases, the design question is not whether the user can present an attestation. The design question is whether the whole data-sharing event can survive review.

Who requested the data? Why was it needed? Which authentic source supports it? Which issuer was authorised? Which identifier was used? What was stored? What decision followed? What happens if the source changes, the attestation is revoked, the match is wrong, or the user challenges the outcome?

Those questions define the wallet as governed public infrastructure. Without them, the wallet remains a polished presentation tool. With them, it becomes a controlled data-sharing layer capable of supporting lawful reliance.

That is the first structural shift the World Bank paper points toward but does not yet complete. Once the wallet is understood as a data-sharing layer, the use cases in the paper become more demanding than the credential model suggests.

High-assurance use cases change the trust threshold

The paper’s use cases are well chosen. Access to social benefits, digital student or professional attestations, and Private Sector Onboarding and e-KYC are not marginal examples. They are precisely the kind of use cases where wallet infrastructure starts to touch money, rights, access, risk and public decisions.

That is why they need a higher trust threshold.

In low-risk settings, a presentation may only need to prove that an attestation was issued and has not obviously been altered. In high-assurance settings, that is not sufficient.

KYC, onboarding, eligibility checks, permits, payments and access to regulated services are not simple presentation events. They are reliance events. A relying party may open an account, approve a benefit, issue a permit, release a payment, deny access or classify risk because of what the wallet presents.

The paper’s e-KYC example says a bank can accept verified attributes ( actually it's an attestation) from a national identity wallet and receive only the necessary attributes, such as age or residence. That is directionally right. But KYC does not end when the attestation is verified. The bank must still know whether the source is authentic, whether the issuer was authorised, whether the attribute is current, whether the user remains bound to the wallet, whether the relying-party request was legitimate, and whether the event can be reconstructed under audit.

The same applies to benefits. A social protection agency may issue an attestation proving eligibility. A payment agent may verify it offline. But the public consequence is not the scan. The consequence is the payment, denial, duplicate claim, exclusion, appeal or correction that follows from the scan.

That is why high-assurance use cases must be analysed through lawful reliance, not only technical verification.

A valid attestation is one control. It is not the whole trust chain. The trust chain must also cover legal authority, institutional mandate, authentic-source linkage, relying-party entitlement, identifier governance, status and revocation, post-presentation verification, consent lifecycle management, evidence retention and remedy.

The risk becomes sharper where wallet infrastructure links identity, payments and data sharing. The World Bank paper presents that convergence as a benefit. It can be. But convergence without separation creates governance risk. Identity proofing, payment execution, consent or approval, eligibility assessment and service delivery have different legal bases, different failure modes and different remedies.

A high-assurance wallet ecosystem must therefore keep the user experience simple without collapsing the control surfaces behind it. The user may see one wallet interaction. The system must still preserve separate authority chains for identity, attestations, payment instructions, data sharing, relying-party validation and dispute resolution.

High assurance does not mean unnecessary friction. It means evidence discipline. It means the system can prove who requested what, why it was needed, which source supported it, how the match was made, what decision followed, and how correction or remedy can operate if the decision is wrong.

This is the difference between a wallet that works in a pilot and a wallet that can survive audit, dispute and public reliance. A pilot proves that an attestation can move. A high-assurance ecosystem must prove that the resulting decision can be defended, corrected and reversed when needed.

That is the standard governments and regulated sectors should apply before treating wallet presentations as operationally reliable.

Sole control is an assurance condition, not a privacy slogan

User control is one of the paper’s strongest promises. The paper says wallets support user empowerment and privacy because individuals control which data to share, when, and with whom.

That is directionally right. It is still too light for high-assurance wallet use.

Control is not only a user benefit. It is an assurance condition.

A wallet used for KYC, onboarding, eligibility, permits, payments or regulated access must prove that the identity act remains under the user’s control. That means the user must be able to see who is requesting data, what is being requested, why it is being requested, what will be shared, what has been shared, and how the transaction can later be challenged.

A consent screen is not enough. A privacy notice is not enough. A selective disclosure feature is not enough if the relying party can still over-request, retain, correlate or reuse the data outside the purpose for which it was disclosed.

Sole control has to be operational. It must appear in the wallet interface, the transaction record, the relying-party rules, the identifier strategy, the audit trail and the remedy path.

This is where benefit language needs to become governance language. User empowerment should be translated into inspection-ready controls: transaction history, relying-party identification, purpose display, selective disclosure, consent or approval evidence, erasure request, suspicious-request reporting, correction routes and recovery support.

The user should not only be able to present an attestation. The user should be able to understand and later reconstruct the act of presentation. That includes the identity of the relying party, the category of data requested, the purpose asserted, the data actually shared, the time of disclosure, and the downstream service or decision connected to it.

Without that evidence, control becomes symbolic. The user appears to choose, but cannot prove what happened. The relying party appears to receive data lawfully, but cannot show the full basis for reliance. The ecosystem appears privacy-preserving, but cannot answer a complaint, audit or dispute.

This is why safeguards before framework is not only a sequencing point. It is an assurance rule. Safeguards must be translated into enforceable system behaviour before the wallet is treated as trusted infrastructure.

For high-assurance use cases, sole control means more than choosing which attestation to share. It means the user remains visible in the chain of authority, disclosure, reliance, evidence and remedy. If that chain disappears after the scan, the wallet is not under meaningful user control. It is only a polished interface over an ungoverned exchange.

Post-presentation verification is the missing layer

The most important gap appears after the wallet presentation.

Most wallet discussions explain how an attestation is issued, stored, presented and verified. The World Bank paper largely follows that structure. It explains the movement of the attestation, but not enough of what happens after the relying party receives it.

That is where the real governance problem begins.

Post-presentation verification is the governance and evidence process that determines what happens after a wallet presentation is received. It asks whether the relying party may use the data, whether validity or status must be checked again, whether the data may be retained, whether the identifier may be matched, whether the decision can be audited, and whether correction or revocation must propagate.

A attestation presentation is not the end of the transaction. It is the start of a reliance event. After the presentation, the relying party may match the data, verify it, store it, combine it with existing records, trigger a risk check, approve a service, deny access, release a payment, create an account, or make a decision that the person may later need to challenge.

That post-presentation layer must be governed.

The paper says that verification can occur directly between the holder and verifier, reducing dependence on centralized systems. That can be true in a narrow technical sense. But in high-assurance use cases, the relying party still needs to know whether the presentation may be relied upon for the specific purpose at hand without a user wallet involved.

Post-presentation verification asks the questions that technical presentation does not answer. Was the relying party entitled to request the data? Was the shared identifier used only within the authorised context? Was the attestation current at the moment of reliance? Was a status check required? Was the data retained? Was it matched to the correct record? Did the relying party create an evidence record? What happens if the authentic source later corrects the underlying fact?

These are not edge cases. They are the normal operating conditions of KYC, onboarding, benefits, permits, payments and regulated access.

A bank cannot stop at a successful presentation. It must be able to show how the wallet disclosure supported customer due diligence, what was retained, how identity was matched, and how the decision can be reviewed. A benefits agency cannot stop at the scan. It must be able to explain why a person was paid, denied, flagged or asked for further evidence. A permit authority cannot stop at the attestation. It must be able to defend the decision that followed.

This is why governance plus evidence must govern more than issuance and verification. It must govern reliance after presentation: retention, matching, status refresh, revocation effects, correction propagation, audit evidence and remedy.

Post-presentation verification should therefore be treated as a distinct wallet governance layer. It does not replace attestation verification. It extends it into the part of the transaction where rights, access, obligations, risk decisions and payments are actually affected.

Without that layer, the ecosystem can prove that an attestation moved correctly. It cannot prove that the decision made from it was lawful, necessary, attributable, auditable, correctable or reviewable.

The consent lifecycle must survive the first click

Consent language often concentrates too much attention on the moment of approval. A person sees a request, presses a button, and the system records that something was allowed.

That is not enough for wallet-mediated data sharing.

The World Bank paper presents wallets as tools for user control and data minimisation. That is important, but the real test is not whether the user can approve a disclosure once. The test is whether the whole consent or approval lifecycle survives after the first click.

A wallet transaction is rarely isolated. In high-assurance use cases, the relying party may retain data, match it against internal records, trigger a decision, share evidence with another department, repeat checks over time, or use the disclosure to satisfy a regulatory obligation. A single approval screen cannot govern all of that by itself.

Consent lifecycle management must therefore cover the full chain: request, review, disclosure, retention, reuse, withdrawal, correction, erasure request, evidence and remedy.

That does not mean every wallet transaction depends on consent as the legal basis. KYC, benefits, permits, payments and regulated access may depend on legal obligation, public task, contract, eligibility rules or regulatory duty. But even where consent is not the legal basis, the user-controlled disclosure event still needs lifecycle management. The person must know what was requested, what was shared, why it was needed, who relied on it, and how the downstream record can be corrected or challenged.

This is where interface language can mislead. A button may approve a disclosure, but it does not prove that later retention is lawful. A consent toggle may look like withdrawal, but it is not meaningful if the stop condition cannot reach the relying party or be reconstructed under review.

That is why consent lifecycle management matters. Data sharing does not become lawful because a platform or wallet makes transmission possible. It becomes lawful when the request, purpose, data, mandate, evidence and remedy remain connected throughout the lifecycle.

For a high-assurance wallet, consent lifecycle management should answer practical questions. What did the relying party request? What did the wallet disclose? What was the stated purpose? What could the relying party retain? Could the person later see the transaction? Could they request erasure or correction? Could a supervisor or court reconstruct the event?

If those questions cannot be answered, user control is fragile. The wallet may support a neat disclosure experience, but the governance of the data after disclosure remains weak.

A wallet ecosystem should therefore be judged not only by how easily a person can share an attestation. It should be judged by whether the disclosure remains traceable, bounded, reversible where appropriate, and capable of supporting remedy after the transaction has moved beyond the screen.

Shared identifiers are not the enemy; uncontrolled correlation is

The identifier question is often handled too defensively.

Wallet guidance tends to treat identifiers as a privacy problem to be minimised as far as possible. That instinct is understandable, but it is incomplete.

No serious multi-party data-sharing ecosystem can survive without an identifier strategy.

KYC, onboarding, eligibility checks, permits, payments and regulated access all depend on matching the right person, record, attestation, relying party and service decision. If the ecosystem cannot identify the subject reliably, it cannot verify eligibility, prevent duplication, detect fraud, correct errors, propagate revocation, or reconstruct a disputed transaction.

The problem is not the existence of identifiers. The problem is uncontrolled correlation.

A shared identifier can create risk when it is reused outside its proper context, silently linked across services, retained without purpose, matched without authority, or used to build profiles that the person cannot see or challenge. But removing stable identifiers entirely creates a different risk: weak matching, false positives, false negatives, duplicate records, failed correction and broken remedy.

For high-assurance wallets, the right question is therefore not whether identifiers should exist. They must. The right question is how identifier use is governed.

Protect the data, govern the identifier.

That does not mean normalising universal, uncontrolled, cross-sector identifiers. It means recognising that high-assurance services require reliable matching, while ensuring that matching remains purpose-bound, accountable and reviewable.

Identifier use should be tied to the service or legal function that justifies it. Cross-context matching should require authority. Linkage events should be evidenced. The user should be able to see where identity-linked data has been disclosed and to challenge the consequences of a wrong match.

This is where the World Bank's credential paradigm becomes weak again. It can describe the attestation. It does not sufficiently describe the matching environment into which the attestation enters.

A wallet presentation may disclose only a small set of attributes, but the relying party may still match those attributes against a wider internal profile. It may connect the presentation to an account, risk file, payment record, eligibility register, sanctions screen, fraud model or case-management system. That matching step is where much of the real governance risk appears.

A high-assurance wallet ecosystem must therefore include unique identifier governance as part of the trust architecture. It should define which identifiers are used, where they are stable, where they are sectoral, where they are pairwise, where they may be linked, and who can authorise that linkage.

The connection does not create entitlement rule still applies. The same is true for identifiers. The ability to match does not create the right to correlate.

A well-governed identifier strategy supports both trust and privacy. It allows the ecosystem to know that the right record is being used, while preventing uncontrolled reuse. It allows correction to propagate to the right relying parties, while preventing unnecessary visibility across unrelated services. It allows audit and remedy, while constraining surveillance.

That is the balance high-assurance wallet guidance needs to make explicit. Do not pretend the ecosystem can operate without identifiers. Do not allow identifiers to become uncontrolled bridges between every context. Protect the data, govern the identifier, and make every material linkage attributable, auditable and correctable.

Authoritative sources, not formats, create public trust

One of the strongest parts of the World Bank paper is its recognition of authoritative sources. It describes them as the official system of record from which authentic data originates.

That is the right direction. It should carry more weight.

An attestation does not become trustworthy because it is in a recognised format. It becomes trustworthy because it can be traced to an authentic source, issued under a valid mandate, presented under user control, validated by an accountable relying party, and challenged through an effective remedy path.

Formats help data move. They do not create public authority.

This matters because wallet guidance often gives too much attention to schemas, keys, signatures, revocation lists, trust lists and exchange protocols. Those components are important. They make verification possible. But they do not answer the deeper governance questions: who owns the record, who is authorised to attest to it, who may rely on it, what happens when the record changes, and who corrects the downstream effect of an error.

The World Bank paper describes credential (attestation) schemas, revocation lists, trust service provider directories and public key registries as part of a broader verifiable data layer. That layer is necessary, but it is not sufficient. A verifiable layer is not the same as a lawful reliance layer.

A relying party can verify that an attestation was signed. That does not prove that the attestation came from the right source, that the issuer had authority for the use case, that the data was current, or that the resulting decision can be defended under review.

This is why trust frameworks cannot be reduced to technical directories and verification rules. They must preserve the chain from legal authority to institutional mandate, from mandate to authentic source, from source to attestation, from attestation to reliance, and from reliance to remedy.

In a benefits use case, the authentic source may be the eligibility register. In a KYC use case, it may be the legal identity record, company register, sanctions source or residence record. In a permit use case, it may be the licensing authority’s register. In each case, the wallet does not create the truth. It carries an assertion whose public value depends on the recognised source behind it.

Authoritative-source governance should therefore be treated as a first-order design requirement. Each attestation should have a clear source, source custodian, issuer mandate, validity rule, correction rule, status rule and relying-party acceptance rule.

Without that chain, wallet ecosystems drift toward format confidence. They can show that data moved securely, but not that the data was authoritative, current, lawfully requested, properly relied upon, or correctable when wrong.

Public trust does not come from the format. It comes from the chain of authority, evidence and remedy behind the format.

A better implementation checklist for high-assurance wallets

The World Bank paper proposes a phased approach to implementation. That is sensible. Wallet ecosystems should not be built as abstract national platforms without use cases, partners, trust rules and operational demand.

The next step is to add a higher assurance checklist.

Governments and donors should not ask only whether a wallet can issue and verify attestations. They should ask whether the ecosystem can survive audit, dispute, correction, revocation, relying-party misuse and operational failure.

Gate	Question	Minimum evidence
Authority gate	What authorises the wallet function and its legal effects?	Current legal or policy instrument defining scope, limits and reviewability.
Mandate gate	Which institution is accountable for issuance, reliance, suspension and correction?	Named authority, delegation limits, escalation route and liability allocation.
Authentic-source gate	Which record is authoritative for each fact?	Source designation, custodian, correction procedure and source-to-attestation traceability.
Relying-party gate	Who may request the data and for what purpose?	Relying-party registration or equivalent onboarding, declared purpose and data request profile.
Attestation gate	What is issued, by whom and under what assurance?	Issuer authority, format profile, status mechanism, validity period and revocation rules.
Wallet-control gate	Does the user retain sole control?	Selective disclosure, transaction history, erasure or complaint route and recovery support.
Identifier gate	How is matching enabled without uncontrolled correlation?	Identifier policy, purpose-bound linkage, logs, minimisation and correction propagation.
Post-presentation gate	What happens after the presentation?	Validation rule, retention rule, status check, decision record and dispute procedure.
Consent-lifecycle gate	Can disclosure permissions or approval events be reconstructed and changed?	Consent or approval evidence, withdrawal or erasure route, propagation and auditability.
Evidence gate	Can an independent reviewer reconstruct the transaction?	Evidence-grade logs, timestamps, provenance, receipts and decision bundles.
Remedy gate	Who can correct, suspend, reverse or compensate?	Operable complaint, review and correction pathway with enforceable deadlines.
Sustainability gate	Who funds assurance operations?	Operating model covering certification, support, incident response, audits and lifecycle operations.

This checklist changes the procurement conversation.

A wallet should not be purchased as an interface, app or technical container. It should be commissioned as part of a governed identity and data-sharing ecosystem.

That means the evidence package matters as much as the software package.

A supplier may demonstrate issuance and presentation. That is not enough. The implementation team must also show who can rely, under what mandate, against which source, through which identifier strategy, with which evidence record, and through which remedy route.

That is the difference between installing a wallet and building trusted infrastructure.

The next wallet debate is about governed reliance

The World Bank paper opens the right conversation. It explains how attestations can be issued, stored, presented and verified. Governments and implementation teams need that first layer.

The next wallet debate has to move further.

For high-assurance use cases, the real question is not whether an attestation can move through the ecosystem. The question is whether the resulting reliance event can be defended.

A wallet used for KYC, onboarding, eligibility, permits, payments or regulated access must do more than support presentation. It must support authority, mandate, authentic-source linkage, sole user control, relying-party accountability, consent lifecycle management, identifier governance, post-presentation verification, evidence and remedy.

That is the difference between a wallet that works in a demonstration and a wallet that can operate as trusted public infrastructure.

The credential paradigm asks whether the attestation is valid. The governance paradigm asks whether the whole transaction is lawful, necessary, attributable, auditable, correctable and reviewable.

That is the standard governments, donors and regulated sectors should apply. Wallets should not be assessed only by format support, cryptographic verification, interoperability claims or pilot performance. They should be assessed by whether they can survive the conditions under which public infrastructure is actually tested: misuse, dispute, correction, revocation, audit, supervision and failure.

A wallet is therefore not a destination. It is a governed passage between records, users, relying parties and decisions. It carries identity-linked data across institutional boundaries, and that movement must remain under control from source to reliance and from reliance to remedy.

The World Bank paper opens the right conversation. The next step is to make the control layer explicit.

An identity wallet becomes trusted public infrastructure only when it proves not merely that an attestation was presented, but that the data-sharing and reliance event was lawful, necessary, attributable, auditable, correctable and subject to remedy.

Source note

This article responds to the World Bank Group paper Digital Wallets 101: A Short Explainer of Digital Wallets and Verifiable Credentials. Washington, D.C.: World Bank Group. Available at: http://documents.worldbank.org/curated/en/099051126134535710

The analysis uses the paper as a constructive starting point and applies the Seven Layers lens to high-assurance wallet use cases, including KYC, onboarding, eligibility, permits, payments and access to regulated services.