TL;DR: Payment governance fails when organizations collapse three different questions into one. Circular 83 governs internal-control systems at commercial banks and foreign bank branches. Broader fintech and payment operations need evidence for services, electronic identity checks, due diligence, retention, privacy, and exceptions, but they should not be described as directly regulated by Circular 83 without a separate legal basis. Decree 23/2025/NĐ-CP adds a distinct electronic-signature and trust-services layer beneath the Law on Electronic Transactions. ComplianceOne connects payment, eKYC, identity, provider, credential, submission, and agreement evidence while preserving strict boundaries: it does not identify suspicious transactions, store card numbers or identity values, verify signatures, determine provider licensing, perform authentication, or transmit filings.
A digital payment business launches a new onboarding journey. Customers verify their identity remotely, accept an electronic agreement, connect an account, and begin transacting within minutes. The commercial experience feels like one continuous flow.
The evidence behind it is not one flow.
One team manages payment-service logs. Another owns customer due diligence. A specialist provider performs identity verification. A trust service supports the signature. Privacy decides how long evidence should remain. Security restricts access to sensitive artifacts. Legal tracks the status of the provider and the agreement. Internal audit asks whether controls operated. When an authority asks what happened to one customer on one date, the answer spans every team.
The easiest mistake is to describe all of this as “Circular 83 compliance” or “open-payments compliance.” That framing is too broad.
Circular 83/2025/TT-NHNN concerns internal-control systems at commercial banks and foreign bank branches. It should not be used as a general legal label for every fintech, e-wallet, payment intermediary, merchant platform, or application programming interface. Those organizations may face other payment, anti-money-laundering, privacy, cybersecurity, electronic-transaction, contractual, or sector duties. Their exact scope requires separate legal analysis.
Decree 23/2025/NĐ-CP is different again. It sits beneath the Law on Electronic Transactions and addresses electronic signatures and trust services. It does not turn a compliance platform into a certificate authority or signing provider.
Good governance begins by keeping these layers distinct, then connecting the evidence that genuinely overlaps.
“The customer journey may be seamless. The legal scope, technical trust, and operational evidence must remain explicit.”
Three Governance Layers, Three Different Questions
An effective operating model separates the layers before designing controls.
Bank internal control asks whether governance works. For an in-scope commercial bank or foreign bank branch, Circular 83 addresses oversight, three lines of defence, compliance, risk management, internal audit, control culture, segregation of duties, policies, material risks, management information, and reporting to the State Bank of Vietnam.
Payment and eKYC operations ask what happened. Which payment service was involved? What did it log? Which identity-verification method was used? Did the attempt pass or fail? Which due-diligence obligation relied on the evidence? How long should the evidence remain, and what happens when retention and minimization duties conflict?
Electronic trust asks what the organization relied on. Which provider supplied the service? What did the organization establish about its standing? Which credential was active, suspended, expired, revoked, or renewed? Who or what reported that a signature check occurred? Which electronic submission was made, and what acknowledgement came back?
These questions can refer to the same customer or transaction, but they do not share one legal conclusion. A platform should connect their records without erasing their boundaries.
Scope Circular 83 Before Using Its Name
Circular 83 establishes internal-control expectations for commercial banks and foreign bank branches in Vietnam. The repository records a main effective date of 1 July 2026, with certain stress-testing, risk-data, model-risk, and banking-book interest-rate-risk provisions phased to 1 January 2028.
The instrument is not a general fintech charter. A technology company may supply services to an in-scope bank, and a payment intermediary may maintain controls that resemble banking practice, but resemblance does not create direct legal scope.
This distinction changes how an organization should communicate internally:
- An in-scope bank can treat Circular 83 as a direct internal-control obligation.
- A related entity outside direct scope may study the controls as a benchmark only after confirming that approach is appropriate.
- A non-bank fintech should identify the instruments that actually govern its license, services, customer data, transactions, outsourcing, and trust relationships.
- A supplier should distinguish its own legal duties from the bank’s contractual and oversight expectations.
Circular 83 also should not be presented as a monetary-sanctions schedule. Its compliance evidence concerns supervisory risk and internal-control effectiveness. Nor should a general compliance platform claim to calculate ICAAP, capital adequacy, stress tests, model validation, or banking-book interest-rate risk. It can organize policies, approvals, workpapers, specialist outputs, findings, and reporting evidence without becoming a banking-risk engine.
The wording matters. “Supports evidence for an in-scope bank’s internal-control program” is credible. “Makes every fintech Circular 83 compliant” is not.
Build a Payment-Service Evidence Inventory
Once legal scope is clear, operational evidence starts with the services the organization actually provides or relies on.
ComplianceOne records payment services, the logging each service performs, and the retention context attached to those logs. It can connect services to electronic identity-verification attempts, customer due-diligence records, obligations, and exceptions. Legal terms and selectable methods come from installed regulatory content rather than being invented as universal payment categories.
This inventory gives governance teams a stable set of questions:
- Which services are active, and who owns them?
- Which systems and providers support each service?
- What evidence is logged, and for how long?
- Which customer checks depend on that evidence?
- Which exceptions remain unresolved?
- Which rules are accepted as directly applicable, and which are retained for reference?
The inventory should not become a transaction-monitoring engine. ComplianceOne contains no risk score, suspicious-activity threshold, or automated suspicious-transaction determination in this capability. It does not file suspicious-transaction reports.
That refusal is important. A record showing that an identity check failed is not, by itself, a finding that a customer or transaction is suspicious. A due-diligence gap is not an automatic financial-crime conclusion. Accountable specialists must evaluate the wider facts under the rules that apply to their organization.
Preserve Failed eKYC Attempts, Not Only Successful Ones
Electronic onboarding evidence is often designed around the happy path. The business records that a customer passed and loses the rejected, interrupted, or inconclusive attempts that explain how the control operated.
ComplianceOne records electronic identity-verification attempts, including failures. The record can identify the method, time, result, issuer context, and protected evidence references. It can connect a verification to customer due diligence and the obligation the due-diligence record is intended to support.
This produces a more defensible history. Reviewers can see whether the control was attempted, what outcome was reported, and whether the resulting due diligence points to any obligation. A record linked to no obligation is shown as unattributed rather than being allowed to imply a relationship that does not exist.
The platform does not store national identity numbers, card numbers, biometric images, biometric templates, masked fragments, or hashes of those values. Instead, it stores a protected reference: the type of material, its custodian, and a handle meaningful only within the custodian’s system.
Avoiding hashes is deliberate. Identity numbers and similar structured values can come from small enough domains that an attacker may recover them by testing candidates. Calling that value “hashed” would create false assurance. The safer design keeps the value outside the compliance record.
Most users receive a redacted view. Access to a restricted handle requires both permission to read the payments evidence and a separate unmask permission. Successful access is recorded. This is stronger than a user-controlled “show sensitive data” flag because the authorization level is represented by a separate access path.
Reconcile Retention With Data Minimization
Payment and identity evidence sits between competing operational needs. Financial-crime, dispute, audit, or sector rules may require evidence to remain available. Privacy principles require organizations not to retain personal data without purpose or beyond the applicable period.
The wrong response is “keep everything because compliance might need it.” The opposite response, deleting evidence without checking dependent obligations, can be equally damaging.
ComplianceOne records the retention rule and the minimization rule as two responsibilities that must be reconciled. Completion requires two named functions to sign. One approval leaves the matter visibly awaiting the second decision. This prevents a generic approval list from allowing one function to satisfy both sides of the tension.
The platform does not decide the retention period. It preserves the rules selected by the organization, the conflict, the responsible reviewers, their decisions, and the resulting evidence. Legal and privacy teams remain accountable for the conclusion.
This is particularly valuable in open-payment ecosystems where several providers hold different pieces of the same journey. The organization should record which custodian holds sensitive material, which evidence it retains itself, which obligation depends on it, and how deletion or restriction will be communicated when the decision changes.
Treat Due Diligence as Evidence, Not a Verdict
Customer due diligence can be linked to identity verification and the obligations it supports. The value is attribution: a reviewer can see why the record exists and which evidence informed it.
The danger is overstatement. A due-diligence record does not prove that the organization met every anti-money-laundering duty, and an electronic identity result does not establish the absence of fraud. It records one part of an accountable process.
A strong review therefore asks:
- Is the customer or entity correctly referenced without duplicating restricted values?
- Is the verification result, including failure, preserved?
- Is the verification evidence held by a named custodian?
- Is the due-diligence record linked to the obligation it supports?
- Are exceptions assigned to an accountable reviewer?
- Is the retention decision complete, including the privacy side of the decision?
This approach improves auditability without claiming that software made a financial-crime determination.
Keep Electronic Trust Evidence Separate From Payment Evidence
Electronic signatures and trust services support many payment journeys, but they are not payment controls by another name.
Decree 23/2025/NĐ-CP is recorded as effective from 10 April 2025 beneath the Law on Electronic Transactions. Its operational themes include electronic signatures, certificates, trust-service providers, credential lifecycles, authority interaction, and evidence about non-repudiation. The current regulatory content distinguishes timestamp issuance, data-message certification, public digital-signature certification, and safe specialized electronic signatures. Applicability and interpretation still require qualified advice.
ComplianceOne provides registers for identities, trust providers, electronic submissions, and electronic agreements. Installed regulatory content declares the available trust-service types, verification methods, assurance levels, identity-attribute types, and agreement types. Where an instrument declares no list, the platform does not borrow one from a neighboring instrument merely to fill a selector.
This content-driven model matters because “electronic trust” is not a universal vocabulary. Different instruments regulate different services and evidence. The record should show which regime and version supplied the terms used at the time.
Record Providers Without Determining Their License Status
An organization relying on a trust service needs to know which provider it used, for which service, and what it established about the provider’s standing.
ComplianceOne records that organizational assessment. Unknown is a valid default. A company that has not checked a provider should not be defaulted into a positive or negative claim. Where the applicable content requires a recognized provider for a service type, the platform can refuse an incompatible record based on the organization’s recorded status.
The supervising authority’s published information remains the source of truth. ComplianceOne does not determine that a provider is licensed, certified, or currently recognized. It records what the organization checked, when, using which evidence.
This distinction is important for procurement and vendor governance. A provider record should carry the review date, service scope, evidence, accountable owner, and next review action. It should not turn an internal assessment into an official licensing statement.
Make Credential Status a History
A spreadsheet with a certificate-expiry column can show today’s status. It cannot reliably show whether the credential was valid on the day the organization relied on it.
ComplianceOne records credential status changes as events. Issuance, suspension, revocation, expiry, and renewal carry a timestamp, actor, reason, and evidence. Revocation and expiry are terminal. Renewal creates a successor record rather than reopening history.
This lets an investigation reconstruct the credential’s state at the relevant time. It also avoids the common failure where a current “active” status overwrites evidence that the credential was suspended for part of the period.
The platform does not issue a certificate, store private keys, suspend a credential at the provider, or check a revocation service. Lifecycle permissions control who may record those organizational events. Customers may separate ordinary maintenance from lifecycle changes, but they must configure their roles to achieve the intended separation.
Record Signature Verification Without Performing It
An electronic agreement can connect parties to signature evidence. Verification metadata can show the method, time, result, issuer, assurance context, and evidence reported by an external tool or provider.
ComplianceOne records that report. It does not verify the signature.
The distinction protects the trust boundary. A compliance platform should not store signing credentials or key material merely to describe evidence about them. Nor should it rewrite algorithm labels supplied by a verifying tool. The record should preserve what the external source reported, not normalize it into a stronger claim.
Agreement parties are entity references rather than freely typed names. That supports linkage between the organization or person in the agreement and the evidence attributed to that party without multiplying inconsistent identity text.
Decree 23 should also not be marketed as complete across every artifact merely because operational surfaces exist. The current public regulatory content identifies forms numbered 01, 03, and 08 as verified. Other source-instrument content remains subject to source verification.
Preserve Submission Evidence Without Claiming Automated Filing
Authority-facing evidence needs both sides of the exchange: what the organization sent and what came back.
ComplianceOne records the submission channel, payload hash, responsible actor, date, receipt, acknowledgement reference, and amendments. An amendment carries its own hash while the original remains readable. This gives reviewers a traceable pair instead of an overwritten file.
The platform does not transmit the filing. It does not connect to an authority portal merely because a channel is listed. It records that the organization used a channel and retains the evidence received from that interaction.
This boundary should appear in demos and procurement documents. “Electronic submission evidence” means a governed record of a filing. It does not mean one-click regulatory transmission.
Govern Open Payments Through Explicit Relationships
“Open payments” can describe partnerships, embedded finance, interoperable services, application interfaces, account connectivity, or a wider provider ecosystem. The term is commercially useful but legally imprecise. Governance should therefore begin with the relationships rather than the label.
For each service, record:
- The operator and accountable owner.
- The customer journey and systems involved.
- The payment, identity, signing, and infrastructure providers relied on.
- The legal instruments and contracts considered applicable.
- The evidence created at onboarding, authorization, processing, exception handling, and closure.
- The custodian of restricted identity, biometric, card, or credential material.
- The retention and minimization decisions.
- The authority interactions and acknowledgements.
This model supports banks and non-banks without pretending their duties are identical. An in-scope bank can connect Circular 83 internal-control evidence to the payment and provider records its controls oversee. A fintech outside Circular 83’s direct scope can maintain equivalent operational evidence under the rules and contracts that actually apply to it.
A Practical Evidence Architecture
Organizations can implement the model in ten steps.
1. Confirm entity scope. Determine whether the organization is a commercial bank, foreign bank branch, payment intermediary, fintech, technology supplier, merchant platform, or another participant. Do not infer legal scope from branding.
2. Separate the legal layers. Record banking internal control, payment operations, privacy, financial crime, electronic transactions, and trust services as distinct sources of obligation.
3. Inventory payment services. Name owners, systems, providers, logs, retention context, and customer journeys.
4. Map eKYC evidence. Record successful, failed, and inconclusive attempts. Keep restricted values with their custodian and use protected references.
5. Attribute due diligence. Link each record to the obligation it supports. Investigate unattributed records rather than allowing them to look complete.
6. Reconcile retention and minimization. Require both responsible functions to approve the resolution and document what happens to evidence held by third parties.
7. Register trust providers and credentials. Record the organization’s standing check, credential history, evidence, and review dates without implying authority recognition.
8. Link agreements and signature evidence. Preserve entity references and externally reported verification metadata. Keep signing keys and identity values outside the platform.
9. Record submissions and receipts. Preserve the original and every amendment. Do not confuse channel evidence with transmission capability.
10. Rehearse one customer investigation. Reconstruct the service, identity attempt, due diligence, retention decision, provider, credential state, agreement, and relevant submission evidence as of one date.
The rehearsal should expose missing ownership, unexplained retention, unverified provider status, orphaned evidence, and inappropriate access before an external review does.
The Trustworthy Payments Standard
Trustworthy payment governance is not a single dashboard or legal label. It is the ability to explain a customer journey without overstating what the technology or regulation proves.
The standard is clear:
- Scope Circular 83 only to the entities it directly governs.
- Preserve internal-control evidence without pretending to calculate banking risk.
- Record failed eKYC attempts as well as successful ones.
- Keep card, biometric, and identity values outside the compliance record.
- Treat due diligence as attributed evidence, not an automated verdict.
- Resolve retention and minimization through accountable human decisions.
- Record provider standing without impersonating the authority.
- Preserve credential lifecycle as history.
- Record signature checks without claiming to perform them.
- Keep filing evidence and regulatory transmission separate.
This is how a payment organization earns trust: not by claiming one system performs every regulated act, but by proving which specialist performed each act, which evidence was retained, which person decided, and which rule governed the decision.
Ronni K. Gothard Christiansen
Technical Privacy Engineer and CEO, AesirX.io
Laws and standards referenced
- Vietnam: Circular 83/2025/TT-NHNN: internal-control systems for commercial banks and foreign bank branches, including governance, risk management, compliance and internal audit.
- Vietnam: Law on Prevention and Combat of Money Laundering 14/2022/QH15: customer due diligence, identification, records and AML obligations relevant to payment operations.
- Vietnam: Decree 19/2023/NĐ-CP: implementation of provisions of the Law on Prevention and Combat of Money Laundering.
- Vietnam: Decree 52/2024/NĐ-CP on Non-Cash Payments: payment services, payment intermediaries and associated operational requirements.
- Vietnam: Law on Electronic Transactions 20/2023/QH15: legal framework for electronic transactions, data messages, electronic signatures and trust services.
- Vietnam: Decree 23/2025/NĐ-CP: electronic signatures and trust services, including providers, certificates and related electronic trust evidence.
- Vietnam: Personal Data Protection Law 91/2025/QH15: processing, protection, minimisation and accountability for personal data used across payment and identity processes.
- Vietnam: Decree 356/2025/NĐ-CP: implementation of the Personal Data Protection Law, including processing records, impact assessments and protection measures.
Disclaimer
This article provides operational guidance from a platform vendor, not legal advice. The applicability of banking, payment, AML, eKYC, privacy, electronic transaction and trust-service requirements depends on the organization, services and regulatory scope. Requirements should be confirmed with qualified Vietnamese legal and regulatory specialists.
