Legal Document Change Notification, Consent and Retention Policy

1. Purpose
1. Omniwire Inc. (“Company” and “Our” and “We”) must comply with all regulatory requirement and general Business Best Practices to ensure that Our Customers understand how We notify them of: (i) changes in our Legal Documents; (ii) obtain their consent that they have read the Legal Documents; that they (iii) understand the content of the Legal Documents; and (iv) provide their acceptance of the changes.
2. This policy establishes how Omniwire classifies, approves, publishes, and notifies Customers of changes to our Legal Documents.
3. This Policy also documents Our policy and procedures regarding: (i) Evidence of Customer acceptance of the changes; and (ii) retention of these Evidences.
4. How We handle notification to our Third-Party Suppliers of document changes that are relevant to them are described in the contract with each Third-Party Supplier.
5. A robust Change Notification Consent and Retention Policy and Procedures (hereinafter the “Policy”) is paramount to ensuring that people understand their IT security responsibilities, IT security policies, and how to properly use and protect the IT resources entrusted to them. The following guidance provides steps for building and maintaining a comprehensive Information Security Awareness Program, as part of Company’s Information Security Program.
2. Definitions

“Business Days” means any day other than a Saturday or Sunday or United States federal public holiday on which banks are physically open for the transaction of general banking business. Any other day is to be considered a “Calendar Day”.

“Business Relationship” means an ongoing professional connection between two or more parties engaged in commercial activity. It involves shared goals, clear communication, and mutual value.

“Calendar Day” means a single day as it appears on a calendar, running from 12:00 a.m. (midnight) to 11:59:59 p.m. (just before the next midnight) in the relevant local time zone. Different from Business Days and workdays, weekends and federal holidays count toward Calendar Days.

Consent:

“Informed Consent” means the individual receives a full explanation of the changes, and freely agrees to them.

“Implied Consent” means consent is assumed through a Customer’s actions or behavior, such as signing onto their account

“Expressed Consent” and “Explicit Consent” mean direct, clear, and unambiguous permission is given either verbally or in writing without pressure.

“Written Consent” means a signed legal document is executed between the Parties.

“Customer” means a natural person who has a Business Relationship with Us.

“Evidence” and “Evidences” mean anything that makes a fact or idea clear, showing whether it is true or false. It acts as proof, a sign, or a reason to believe something. In Our case it specifically relates to documentation showing a Customer has read, understands and agrees to the disclosures and conditions in Our Legal Documents.

“Legal Documents” means a formal written or digital record that creates, changes, or ends legal rights and duties. It shows proof of an agreement or an official status, and a court can enforce it if someone breaks the rules.

“Legal Rule” means that under 12 C.F.R. § 1005.8(a)(1), a financial institution must mail or deliver written notice at least twenty-one (21) Calendar Days before the effective date of a change to a term required to be disclosed under § 1005.7(b) when the change results in increased consumer fees, increased consumer liability, fewer available electronic fund transfers, or stricter frequency or dollar limits.

“Major Changes” and “Material Changes” mean changes which may reasonably affect a Customer’s decision to use the service, their legal or financial position, or the treatment of personal information. Examples requiring Legal review include, but are not limited to: (i) new or expanded categories of personal information collected; (ii) new or expanded purposes for using information, including AI training or profiling; (iii) new categories of recipients or materially expanded sharing practices; (iv) new products, account features, transfer restrictions, dispute terms or user obligations; (v) new or increased fees, increased liability, fewer available electronic fund transfers or stricter transfer limits; (vi) changes affecting previously collected data or previously granted permissions; and (vii) material.

“Minor Change” means a change which does not materially alter a user’s rights, obligations, fees, liability, data collection, data use, data sharing or available services. Typical examples include: (i) typographical, formatting, grammar or broken-link corrections; (ii) updated contact information or company address with no substantive effect; (iii) clarifying language that does not broaden an existing right, purpose or practice; (iv) organizational or readability changes; and (v) adding a jurisdiction-specific explanation without reducing existing rights, as confirmed by Legal and Compliance.

“Third-Party Suppliers” means an external company or independent business that provides raw materials, components, physical goods, or specialized inputs to an organization. They operate outside the direct control of the buying company and sit upstream in the supply chain.

1. In-Scope Legal Documents
1. The following Legal Documents are addressed by this Policy:
1. Privacy Policy and jurisdictional privacy notices;
2. Terms of Use, account terms and customer agreements designated by Legal and Compliance;
3. Fee Schedules and fee-related disclosures maintained separately or incorporated by reference;
4. E-Sign consent, cardholder agreements and product-specific consents
5. Public websites, email/push providers, customer support tools and the internal admin portal used to deliver or evidence legal content.
2. Responsibilities
1. Chief Compliance Officer (“CCO”)
1. The CCO is responsible for developing, and, when required, making changes to this Policy to ensure it meets all regulatory, and internal policy requirements. Key responsibilities include ensuring that the Policy is updated when new regulations and internal business requirements are encountered and that the Policy is tested, evaluated and updated accordingly, and that proper records of any testing results are maintained.
2. Company General Counsel (“CGC”) and External Legal Counsel (“ELC”)
1. The CGC is responsible for reviewing this Policy to ensure it meets all legal, regulatory, and internal policy requirements. In certain instances, regulations may require that this Policy be reviewed by ELC.
3. Chief Operating Officer (“CEO”)
1. As with all other Company policies and procedures, the CEO has the overall final responsibility to ensure that this Policy is: (i) correctly prepared; (ii) updated according to any changes in business needs; (iii) updated according to any regulatory requirements; (iv) properly administered by all relevant management and staff and (v) reviewed by the Board of Directors according to regulatory and legal requirements.
4. Board of Directors (the “Board”)
1. The Board is responsible to review this Policy document to ensure the Policy are: (i) correctly prepared; (ii) updated according to any changes in business needs; (iii) updated according to any regulatory requirements; (iv) properly administered by all relevant management and staff; and (v) approve or disapprove the Policy and ensure the action taken is recorded in the Board’s meeting minutes.
2. Should the Policy be disapproved, the Board must direct Company management to revise the Policy as needed and resubmit the Policy to the Board within a time limit set by the Board.
3. This Policy shall be reviewed and approved by the Board after any updates / revisions and at least once each year.
3. Legal Documents Changes
1. Notices.
1. We will notify a Customer of all relevant changes to Our Legal Documentation. This notice may be by: (i) Email; (ii) text message; or (iii) a readily apparent notice when a Customer signs on to their account.
2. Notifications will include, but not necessarily be limited to: (i) a concise change summary; (ii) the stated effective date of the change; (iii) the Customer’s required action in regards to the notice; and (iv) if the Customer must respond in the affirmative or negative in regards to the change prior to the Customer taking any actions in the Customer’s account.
3. The notification will, at minimum, provide the following:

1. Change summary – a plain-language description plus a redline or comparison to the prior version.
2. Impact assessment – the rights, obligations, fees, liability, services, data practices and affected individuals.
3. Applicability -the l entity, product, account type, jurisdiction, language and impact on the Customer.
4. Classification - Minor or major/material, with written rationale
5. Legal basis – All applicable authority, contract term or internal policy; record ‘not determined’ until reviewed by the Customer.
6. Required action by the Customer – It is notice only, the Customer’s acknowledgement, the Customer opt-out/choice or affirmative acceptance.

1. Each notice will be clear, accurate and consistent. The approved notice package will identify: (i) the document name, version and effective date; (ii) what changed, in plain language, with a link to the complete document; (iii) who is affected, where segmentation is necessary; (iv) what action, if any, the user must take and by when; (v) available choices or consequences, only as approved by Legal and Compliance; (vi) a contact or support route; and (vii) an accessible format and the user’s supported language where required or operationally available.
1. Acceptance by Conduct, Implied Acceptance and Deemed Acceptance
1. Acceptance by Conduct
1. The Customer may be viewed as agreeing to Our revised Legal Documents through actions or performance instead of a formal signature.
2. Implied Acceptance
1. A contractual rule stating that if a party does not object within a set time or proceeds with the next step, they are legally considered to have accepted the change
3. Deemed Acceptance
1. Moving forward with a new transaction (such as executing a transaction to move funds to another party) knowing the content of the relevant Legal Documents have changed.
2. Notification Procedure

Change type	Minimum treatment	Internal best-practices
Minor	Post the current version with version/effective date; preserve history.	A release note or non-blocking in-app notice where useful.
Major/material	Prominent direct notice and any consent/acceptance that Legal requires.	Email + in-app banner or inbox + login prompt; push as a supplemental channel, not the sole durable notice.
Regulation E qualifying adverse change	Written notice mailed or delivered at least twenty-one (21) Calendar Days before the effective date.	Coordinate email/e-delivery eligibility, in-app copy and support messaging; hold effective date until evidence checks pass.
Security-related immediate change	Follow the applicable exception and later-notice rule if Legal determines 12 C.F.R. § 1005.8(a)(2) applies.	Record incident linkage, emergency approval, permanence decision and follow-up notice evidence.

1. Handling Successful and Failed Delivery of Notice
1. Capture attempted, delivered, bounced, displayed, opened, acknowledged and accepted events separately. A push notification or app banner alone should not be treated as proof of written delivery when a law or agreement requires written notice.
2. Procedures are to: (i) Retry transient delivery failures; (ii) Route hard bounces or missing contact data to a defined exception queue; (iii) Do not infer acceptance from silence unless Legal has approved that treatment for the specific change; and (iv) Do not block access to funds or legally required functionality merely because an unrelated acceptance flow is incomplete.
2. Fee Schedules and Regulation E Treatment.
1. We will keep Our Fee Schedules as separate documents that are clearly linked from Our Terms of Use. Our Fee Schedules are closely Version Controlled.
2. Fee-change workflow. We will:
1. Create a new Fee Schedule version and redline the changes. We will never overwrite the active schedule.
2. Identify every affected fee, transfer feature, account, user cohort, legal entity and jurisdiction.
3. Determine whether Regulation E, payment account rules, a Third-Party Supplier’s requirement, contract or another regime applies.
4. If § 1005.8(a)(1) applies, set the effective date no earlier than twenty-one (21) Calendar Days after compliant written notice is mailed or delivered, using the company’s approved calculation method.
5. Record delivery evidence, publication evidence and the effective-date release control.
6. Update all linked surfaces—Fee Schedule, Terms link, app/web pricing, support content and customer communications—at the approved time.
3. Section 1005.8(a)(2) provides an exception to prior notice when an immediate change is necessary to maintain or restore the security of an account or electronic fund transfer system. If the change becomes permanent and disclosure would not jeopardize security, written notice is required on or with the next regularly scheduled periodic statement or within thirty (30) Calendar Days after the change is made permanent. The CGC or ELC must approve use of this exception.
3. Permissions and Consent Tracking
1. We will maintain a permission/consent ledger for Consent choices and app permissions that materially affect collection or access. We will not represent an operating-system (“OS”) permission as legal Consent, or legal Consent as proof that an OS permission was granted.
2. How Customer contact is achieved and the Evidence collection is documented in the following table:

Item	Evidence	Important distinction
Contacts	requested/prompted; granted/denied/revoked; timestamp; purpose text version; platform/app version	OS access state is separate from any server-side upload or invitation consent.
Camera / photos	state, timestamp, stated purpose and feature context	Capture only the scope needed; device states may change outside the app.
Microphone	state, timestamp, purpose and feature context	Do not infer use from permission alone.
Location	scope (approximate/precise; while-in-use, etc.), timestamp and purpose	Platform vocabulary varies; normalize without losing raw source values.
Biometric authentication	feature enabled/disabled, timestamp and device-bound result	Do not store biometric templates; record only the app-level authentication setting/result where applicable.
Analytics / marketing / cookies	notice version, choice categories, timestamp, region and withdrawal	Honor withdrawal prospectively and preserve evidence according to the approved schedule.
Privacy-policy consent	document version, choice, timestamp and scope	Required only where Legal determines consent—not notice—is the proper basis.

1. Consent Data Retention, Deletion and Legal Holds
1. Preserve prior legal-document versions and acceptance records. The source memo’s preservation intent does not, by itself, establish a universal retention period. To achieve this We must map each record class to the approved enterprise records-retention schedule and privacy notices. The CCO, the CGC and, if relevant the OLC must approve the period, trigger, storage tier and disposal method.
2. Record classes:

Record class	Retention trigger to define	Deletion / preservation control
Published legal documents	Superseded or withdrawn date	Preserve immutable history for the approved period; restrict draft access.
Approval and classification record	Publication, withdrawal or matter closure	Retain rationale, redline, approvers and authority references.
Notice and delivery events	Campaign completion or account closure	Dispose per schedule unless hold, dispute or regulator request applies.
Acceptance / choice events	Acceptance, withdrawal, account closure or end of relationship	Preserve sufficient evidence while minimizing ancillary device/network data.
Permission ledger	Revocation, feature disablement or account closure	Retain evidence separately from content obtained through the permission.
Admin and audit logs	Event date or system decommission	Protect integrity; review privileged access; apply approved archival/deletion job.

1. Deletion requests and legal holds. We will adhere to the following principles and rules:
1. Route Customer deletion or privacy-rights requests through the approved privacy-request workflow; this policy does not create or expand a statutory right.
2. Before deletion, evaluate exceptions or preservation duties applicable to transaction records, fraud/AML records, disputes, litigation, regulatory inquiries and contractual evidence.
3. A legal hold suspends ordinary deletion only for the records and custodians within its scope. Record the hold identifier and release date.
4. Where the acceptance record must be preserved, minimize or segregate ancillary fields that are no longer required.
5. Run and evidence scheduled deletion jobs; investigate failures and reconcile downstream replicas, backups and vendors under the approved deletion design.
1. Internal Administration Workflow
1. We will use role-based workflow with separation of Legal Document creation, approval and publishing. No administrator may silently replace an active Legal Document or backdate an effective date. The following table describes Our administrative processes:

Stage	Primary owner	Required output
1. Intake	Legal / business owner	Change request, driver, affected document and requested date
2. Draft	Compliance or Legal	New version, redline, plain-language summary
3. Assess	Legal + Compliance + Product	Classification, scope, consent/notice decision, regulatory analysis
4. Configure	Authorized creator	Entity/product/country/language, channels, dates, acceptance gate
5. Review	Legal + Compliance + operational approvers	Approved content, translations, campaign and rollback plan
6. Test	Product / Engineering / QA	Artifact hash, routing, accessibility, event logging and evidence export
7. Schedule	Authorized creator	Locked version and publication/notification/effective timestamps
8. Publish & notify	Platform services	Immutable publication
9. Monitor	Operations + Compliance	Delivery failures, acceptance funnel, incidents and complaints
10. Close	Legal / Records owner	Superseded version archived; evidence package and review date recorded

1. Administration Controls
1. We will implement and adhere to the following Administration Controls: (i) Role-based access for drafter, reviewer, approver, publisher and read-only auditor; (ii) Multi-factor authentication for privileged users and periodic access review; (iii) Two-person approval for production publication, unless an emergency procedure approved by Legal and Security is invoked.; (iv) Immutable audit events for create, edit, compare, approve, reject, schedule, publish, withdraw, restore and export actions; (v) Preview and test-user targeting before production release; (vi) Date guards preventing an effective date from preceding a required notice period; and (vii) Rollback by activating a previously approved version or emergency replacement version—never by deleting history.
1. Roles and Accountability
1. The following table identifies specific roles and their responsibilities:

Role	Responsibilities and Accountability
Legal	Own policy interpretation, classification, legal applicability, notice/consent decision, content approval and exceptions.
Compliance	Reviews policy interpretation, classification, applicability, notice/consent decision, content approval and exceptions.
Product	Translate approved requirements into customer journeys and avoid dark patterns or unintended access blocks.
Engineering	Implement versioning, targeting, delivery, acceptance, integrity, access control, monitoring and evidence exports.
Information Security	Review privileged access, log integrity, encryption, incident response and security-change exceptions.
Customer Operations	Prepare support content, escalate complaints, handle failed-delivery queues and avoid giving legal interpretations.
Records Management / Data Governance	Maintain the approved schedule, legal-hold integration and disposal evidence.
Internal Audit / Assurance	Test design and operating effectiveness independently, based on risk and approved audit plans.

1. Exception, Monitoring and Review
1. Exceptions require a written owner, rationale, risk assessment, compensating controls, Legal and Compliance approval, expiration date and remediation plan. Emergency changes must be retrospectively reviewed promptly under the approved incident/change procedure.
2. Creation owners must monitor at least: (i) documents published without complete approvals or required notice lead time; (ii) hash or artifact mismatches across app, web and downloadable copies; (iii) failed or unprocessed delivery events; (iv) acceptance events that do not resolve to an immutable version; (v) privileged access changes and anomalous admin actions; (vi) retention/deletion job failures and legal-hold conflicts; and (vii) customer complaints indicating unclear notice, inaccessible content or incorrect targeting.
3. Legal and Compliance reviews this policy at least annually and when relevant law, product architecture, data practices, sponsor-bank requirements or customer agreements materially change.

Version History

Creation and Revision History
Date	Revision	Performed by:
August 18, 2026	Original Document	Mark W Wheeler, CCO
August 28, 2026	Original Document Approval	Board of Directors