Loyalty Program Identity Verification and Data Retention
This source-dated reference compares identity collection, verification events, retention criteria, sharing or linkage, and account roles across nine loyalty systems. Each verb remains separate, and an account record does not prove presence, travel, ownership, or wrongdoing.
/* Not legal advice. This page is research, not compliance guidance. */ /* */
What this nine-system reference can establish
The nine systems publish different verification events and different retention periods or criteria; collection is not verification, and no account record proves presence, travel, ownership, or wrongdoing.
This reference uses a frozen roster of three airline systems, three hotel systems, and three issuer systems. The airline rows are AAdvantage, MileagePlus, and SkyMiles. The hotel rows are Hilton Honors, IHG One Rewards, and Marriott Bonvoy. The issuer rows are American Express Membership Rewards, Capital One Rewards, and Chase Ultimate Rewards. Inclusion defines the page's comparison boundary; it does not create a product-selection conclusion, and the alphabetical order within each group carries no preference.
Every system is compared through the same five fields: identity data collected, documented verification events, retention rule, sharing or linkage, and roles and responsibility. Those fields are not interchangeable. A name or contact field requested at enrollment does not establish that the system later checked it. A documented login, recovery, support, or account-change event does not establish how long every related record remains. A partner link does not establish public visibility, and an account role does not establish legal access outside the cited terms.
The table values come only from the 45 accepted m_points_program cells named by the brief. Each cell stays attached to its provider, product or program, jurisdiction, captured revision, source class, source URL, date, and accepted record. Provider language is not widened into a statement about every loyalty program. A criterion expressed in the provider's own terms remains a criterion; it is not converted into a number of days or years. A scoped unknown remains an unknown rather than becoming a negative claim.
This page is a REFERENCE limited to the five published identity-data fields in the accepted record set. It does not extend those fields into a broader conclusion about a system or its users. The Travel hub loyalty and location-history answer block supplies the parent context for reading loyalty-system records without treating them as a complete account of a person's conduct.
Airline loyalty systems: collected data, verification events, and retention
AAdvantage, MileagePlus, and SkyMiles each document provider-specific verification events and retention criteria, while their enrollment collection fields remain separate from both.
The airline table starts with collection because that field defines what the accepted source says the system requests or receives within its captured scope. It does not label every collected field as verified. Enrollment, profile maintenance, booking, support, account access, and another event may appear in different source records, so the cell preserves the event and source boundary rather than compressing them into one universal airline workflow.
Verification receives its own column. The column reports only the event, requested information, actor, and program scope supported by the accepted record. A check documented for login, recovery, support, an account change, or a linked account stays tied to that event. The existence of one documented event does not establish that the same process applies at enrollment, during every transaction, or across another airline's system.
Retention also remains provider- and category-specific. A fixed duration prints only when the accepted cell supplies one for the named record category and scope. A purpose-based, legal, operational, dispute, fraud-prevention, or account-status criterion remains in the source's own bounded form. The page does not calculate an end date, merge unlike record categories, or turn silence about one category into permanent retention or immediate deletion.
Sharing or linkage and roles appear as bounded context. A partner relationship, linked account, household mechanism, authorized actor, or member responsibility is not rewritten as identity verification. It also does not establish public visibility, legal access, physical presence, or actual use. Read each row horizontally only after keeping the five columns separate; the cells describe different actions even when they concern the same program.
| Program | Identity data collected | Verification events | Retention rule | Sharing or linkage | Roles and responsibility |
|---|---|---|---|---|---|
| airline-aadvantage | American's March 2026 policy lists account-profile, payment, partner-transaction, and corporate-program information for enrollment, account use, and management of Program Services.source | The March 2026 terms name account audit, voluntary account termination, name change, and the limited deceased-member transfer-document review as verification or documentation events, with the stated matching information or documents.source | American's March 2026 policy says Travel Services and Program Services information is generally retained up to seven years after completed travel or membership termination, within its stated necessity and legal criteria.source | American's March 2026 policy describes booking-to-account linkage, its named affiliate/travel/co-brand/service-provider/payment recipient categories, and the fields a partner can access when an AAdvantage login is used on the partner's site or app.source | The March 2026 terms define an individual member, a narrow approved administrative-support role, the member's responsibility for that use, and a prohibition on third-party online-service account access.source |
| airline-mileageplus | The current MileagePlus rules state that program participation authorizes United to collect, maintain, use, process, and share names, email addresses, physical addresses, account information, and other information under United's Privacy Policy.source | The rules name password or other security measures for specified transactions and awards, documentary proof for some credit claims, and account validation for changes to a business member's authorized representative.source | The rules state that accrued mileage remains in an account until redemption or forfeiture under six named rule, conduct, law, closure, death, or nonresponse events.source | The rules name audit contractors, defined MileagePlus Partner categories, agreed cross-program mileage-credit contexts, and program-participation information sharing under United's Privacy Policy.source | The rules define individual members, non-individual business members and their authorized representatives, companion travelers, and authorized persons in death or divorce transfers, with stated account-control or responsibility boundaries.source |
| airline-skymiles | Delta's May 2026 Global Privacy Policy lists identity, contact, SkyMiles-account, program-activity, partner-membership, corporate-association, birth-date, gender, login, and consented lounge-access image data for the SkyMiles/account context.source | Delta's current SkyMiles help page documents MFA for login and password reset, the Identity Verification Form and documentary checks for specified account changes or inaccessible accounts, and both account numbers and passwords for duplicate-account authorization and name validation.source | Delta states a necessity/record-policy/legal-requirement retention criterion rather than a public fixed period. Its rules say Delta retains the SkyMiles number assigned to basic information after closure, while its help page separately says account deletion permanently removes access to the account and associated data.source | Delta's May 2026 policy lists nine recipient categories, including authorized representatives, same-booking customers, service and travel partners, other airlines, corporate-travel recipients, payment firms, business-sale counterparties, and government/legal-process recipients. No standalone linked-account terms page was established from the documents read.source | The program rules define an individual-member account, distinguish business-entity and parent/guardian enrollment boundaries, make the member responsible for password confidentiality and use, and prohibit giving another person or third-party service access to the account credentials.source |
Source: 3 programs. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.
Field definitions
- Identity data collected
- Identity or account data the accepted provider record states is collected within its named event, program, jurisdiction, and revision.
- Verification events
- A documented event, requested information, actor, and scope in which the accepted provider record states that verification occurs.
- Retention rule
- The duration or purpose-based retention criterion, covered record category, trigger, exception, and scope stated by the accepted provider record.
- Sharing or linkage
- A documented recipient, partner, linked-account relationship, purpose, and scope without an inference of public visibility or legal access.
- Roles and responsibility
- The account-holder, member, authorized actor, guest, partner, or other role and responsibility boundary stated by the accepted record.
Hotel loyalty systems: collected data, verification events, and retention
Hilton Honors, IHG One Rewards, and Marriott Bonvoy document event-specific account checks and provider-specific retention criteria, while collection, linkage, and account roles remain separate fields.
The hotel table applies the same field grain used for the airline rows. Collection states only what the accepted record places within a named enrollment, profile, reservation, browsing, property, support, or other captured context. The presence of a field in one context does not establish that every property, channel, partner, or account event requests it. The page preserves the source's program, controller, jurisdiction, and revision boundaries instead of describing a single hotel-industry practice.
Verification is limited to the documented event. A login security step, recovery process, support interaction, account change, partner-linking step, or telephone request may have a different actor and purpose. The table does not treat a member number, contact field, reservation field, or linked-account code as proof that the provider verified every associated real-world fact. It reports the event and requested information the accepted cell supports.
Retention is read by record category and criterion. An account-inactivity rule is not automatically a schedule for browsing, reservation, property, security, support, or request records. A general business-purpose criterion does not become a fixed duration. A duration attached to one category does not extend to every other category. Exceptions and regional terms remain with the cell that carries them, and the page does not reconcile two provider statements into a broader rule.
The sharing or linkage field identifies only the documented recipient, partner, account relationship, or operational context. The roles field identifies only the member, guest, property, partner, authorized actor, or other responsibility boundary supported by its accepted record. Neither field proves public visibility, legal access, presence at a property, completion of a stay, account ownership beyond the cited term, or wrongdoing. Those conclusions require different evidence and are outside this matrix.
| Program | Identity data collected | Verification events | Retention rule | Sharing or linkage | Roles and responsibility |
|---|---|---|---|---|---|
| hotel-hilton-honors | Hilton's July 2026 terms name three required enrollment fields and additional profile fields a member may provide.source | Hilton's help page documents password-plus-code Enhanced Security for account access.source | Hilton's August 2026 statement publishes a purpose-based criterion, a usual contractual/legal period, and a destruction standard.source | Hilton's terms say relevant personal information may be shared with business partners to credit mileage or other program benefits.source | Hilton's terms define individual-member eligibility and assign account-access security responsibilities to each member.source |
| hotel-ihg-one-rewards | IHG's July 2026 statement names identity, contact, account, preference, partner-membership, stay, and purchase fields collected for loyalty enrollment and participation.source | IHG's June 2026 terms state that a member requesting a name change through Customer Care should be prepared to provide supporting legal documentation.source | IHG's July 2026 statement uses a purpose-based retention criterion and names longer transactional-record and prospective-litigation exceptions.source | IHG's July 2026 statement names loyalty and co-brand partners and service providers, with product, program-operation, and advertising purposes.source | IHG's June 2026 terms define an individual member role, one-account and registered-guest constraints, and responsibility for account/password access and use.source |
| hotel-marriott-bonvoy | For the loyalty-identity workflow, this cell records six Marriott-listed categories: identifying, demographic, government-ID, financial, loyalty-program, and travel information.source | Within the member-account administration clauses, the September 2026 terms name Member Support security questions and supporting documentation for legal-name changes as verification or confirmation events.source | Marriott's August 2026 statement uses purpose, ongoing-relationship, legal-obligation, and legal-position criteria rather than one universal duration.source | Marriott's August 2026 sharing section identifies Marriott affiliates and property participants, licensees and co-brand issuers, on-property and travel providers, linked-account and insurance partners, advertising partners, corporate recipients, and service-provider functions.source | For the member-account role, the September 2026 terms define individual membership, prohibit joint or shared accounts, require duplicate accounts to be combined, and assign the member responsibility for current, accurate profile information.source |
Source: 3 programs. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.
Field definitions
- Identity data collected
- Identity or account data the accepted provider record states is collected within its named event, program, jurisdiction, and revision.
- Verification events
- A documented event, requested information, actor, and scope in which the accepted provider record states that verification occurs.
- Retention rule
- The duration or purpose-based retention criterion, covered record category, trigger, exception, and scope stated by the accepted provider record.
- Sharing or linkage
- A documented recipient, partner, linked-account relationship, purpose, and scope without an inference of public visibility or legal access.
- Roles and responsibility
- The account-holder, member, authorized actor, guest, partner, or other role and responsibility boundary stated by the accepted record.
Issuer rewards systems: collected data, verification events, and retention
American Express Membership Rewards, Capital One Rewards, and Chase Ultimate Rewards separate issuer enrollment or additional-user collection from account-access verification and from retention criteria.
The issuer table reports the accepted identity fields at the event grain supplied by each record. Information collected for an issuer account, business relationship, additional user, employee user, account manager, or online service remains tied to that context. The page does not assume that every issuer requests the same fields, that one role supplies every field, or that a field collected for one relationship is collected again at each later event.
Verification has its own boundary. An account-access check, registration step, risk or fraud response, identity-document request, additional-user process, or business-account event is reported only when the accepted record supports that event. A verification event for one person or role does not establish a check of every person connected with the account. It also does not establish that a separate public record was consulted.
Retention remains tied to the named record category, trigger, purpose, legal or operational criterion, duration when one is supplied, exception, and scope. Issuer account records, online information, security records, request records, and program records cannot be given one shared schedule unless the source actually gives one. The matrix therefore preserves provider language instead of selecting the most specific-looking duration and applying it to unrelated categories.
Sharing or linkage records a disclosed relationship among an issuer, account, partner, service, additional user, reporting channel, or other named recipient. Roles and responsibility records the boundaries the cited terms place around a primary account holder, business, employee user, account manager, additional user, or authorized agent. Collection does not prove verification; verification does not prove indefinite retention; linkage does not prove public visibility; and a role does not by itself establish legal access or real-world conduct.
| Program | Identity data collected | Verification events | Retention rule | Sharing or linkage | Roles and responsibility |
|---|---|---|---|---|---|
| issuer-amex-membership-rewards | American Express's current Additional Card page says a request requires the additional user's legal name, address, date of birth, and SSN or ITIN, with a telephone route when the user has neither identifier.source | At an Additional Card request, American Express says it obtains, verifies, and records information about the additional user; the requester confirms the relationship, accuracy, and consent for identity verification.source | American Express states an event-based rule for covered Online Information rather than a fixed duration, with legal, regulatory, litigation, and investigation exceptions.source | The May 2026 Business Card Privacy Notice identifies everyday-business, service-provider marketing, business-partner, and co-brand sharing contexts and states the associated opt-out boundary.source | The June 2026 Business Gold agreement defines the Basic Card Member, Company, and Additional/Employee Card Member roles, assigns account and charge responsibility, and states the approval boundary for replacing the Basic Card Member.source |
| issuer-capital-one-rewards | Capital One Business's March 2026 application guide says a business-card application may typically call for the listed contact, entity, applicant, tax, operational, financial, and ownership/controller information.source | Capital One's May 2026 policy names application, login, account-access, and later online or phone interactions as identity or account-verification events.source | Capital One's May 2026 policy uses a reasonably-necessary criterion and lists service, compliance/audit, complaint/troubleshooting, and legal-claim factors; it publishes no fixed duration in this clause.source | Capital One's May 2026 policy lists seven recipient categories, their stated examples or purposes, aggregate/de-identified sharing, and the policy's U.S.-audience scope and non-Capital-One exclusions.source | Capital One Business's September 2026 account-manager page distinguishes the account manager, authorized user, and primary account holder and states each role's controls or responsibility.source |
| issuer-chase-ultimate-rewards | Chase's business-card application guide lists business identity, address, structure, tax, revenue, operating-history, and employee-count fields used for most applications.source | Chase's online privacy policy names access to account information as an example identity-verification event.source | Chase's December 2025 California disclosure ties retention to an ongoing relationship or stated-purpose need, applicable limitation periods, legal retention requirements, and legal claims.source | Chase's policy names service providers, affiliates, co-brand companies, corporate-transaction parties, and legal or protective recipients.source | The Ink Business Preferred Ultimate Rewards agreement distinguishes the responsible party from an authorized user and assigns the responsible party responsibility for points use.source |
Source: 3 programs. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.
Field definitions
- Identity data collected
- Identity or account data the accepted provider record states is collected within its named event, program, jurisdiction, and revision.
- Verification events
- A documented event, requested information, actor, and scope in which the accepted provider record states that verification occurs.
- Retention rule
- The duration or purpose-based retention criterion, covered record category, trigger, exception, and scope stated by the accepted provider record.
- Sharing or linkage
- A documented recipient, partner, linked-account relationship, purpose, and scope without an inference of public visibility or legal access.
- Roles and responsibility
- The account-holder, member, authorized actor, guest, partner, or other role and responsibility boundary stated by the accepted record.
What sharing, linkage, and account roles do not establish
A provider's account or partner linkage states a documented data relationship, not proof of presence, travel, ownership, public visibility, legal access, or wrongdoing.
Sharing or linkage is a relationship field. It may identify a recipient category, program partner, linked account, co-branded relationship, employer or business context, property or operator context, service provider, or another purpose named in the accepted record. The field supports only the relationship and scope its source states. It does not show that every possible data category moved, that every listed recipient received the same information, or that the relationship remained unchanged after the capture date.
Account roles answer a different question. A member, primary holder, additional user, employee user, account manager, guest, partner, property, authorized agent, or other named actor may have duties or permissions under the cited terms. That role label does not by itself establish who supplied a particular field, who completed a verification event, who controlled another person's data, or who performed an action associated with the account. The roles column remains separate because responsibility language cannot safely stand in for collection, verification, retention, or sharing.
Public visibility is another separate state. Nothing in a collection, verification, retention, partner-linkage, or account-role cell should be rewritten as a claim that the information appears in a public search system. A public-display claim would need its own source naming the system, the displayed field, the searchable audience, the jurisdiction, and the effective date. This comparison contains no public-record column and does not infer one from provider possession.
Legal access is also distinct from public visibility. A record may describe disclosure under a legal process, a privacy-rights process, or another controlled path without establishing open public access. Conversely, a role or partner relationship does not establish the authority for a legal request. The page therefore keeps recipient relationships, access mechanisms, and public display as different questions even when the same provider document discusses more than one.
Finally, an account record is not a complete conduct record. Collection can show that a system received data within a documented context. Verification can show that a documented check was described for a named event. Retention can show the provider's stated period or criterion. Sharing or linkage can show a documented relationship. A role can show a term-defined responsibility boundary. None of those cells alone proves physical presence, completed travel, ownership of every linked account, identity beyond the cited process, or unlawful conduct.
Freshness, verified absences, and corrections
This comparison reports what each cited first-party source stated at capture; a missing duration or event becomes a scoped verified absence only when the accepted record names the pages searched.
Provider notices, program terms, security pages, support pages, and account materials can change. Each table value therefore keeps the capture date and provider revision available in its accepted cell rather than presenting the statement as timeless. A later policy may narrow, widen, rename, or reorganize a category. The captured record remains evidence of the cited revision and scope, not evidence that the same wording still appears after the recorded date.
Freshness is assessed per cell rather than per brand or per page. Updating one identity-collection source does not refresh the verification, retention, sharing or linkage, and roles cells automatically. Each field needs its own current source, capture date, and accepted record. Where one source supports more than one field, each cell must still preserve the passage and scope that support its own displayed statement. This prevents a newly captured policy date from making older terms or support instructions appear equally current.
The comparison contains 45 cells: five fields for each of nine preregistered systems. Each cell retains its provider, program, jurisdiction, source, capture date, and revision boundary. The page uses those cells only for the field and scope they document; one cell cannot fill, refresh, or qualify another.
A verified absence has a narrow meaning. It is available only when an accepted record identifies the specific field, the source boundary, and every page searched under the declared method. The rendered badge must preserve those searched pages and the record's scope. It must not be shortened to never collected, never checked, deleted, retained forever, no sharing, no access, or no role. If a record carries an unresolved gap rather than a verified absence, the gap remains held and does not become page copy.
Corrections must also remain cell-specific. A change to one provider, program, jurisdiction, event, record category, or revision does not automatically change another row or another column. The correction path should identify the affected row and field, the new first-party source, its revision or effective date when stated, the capture date, and the exact statement that changed. The replacement then follows the same acceptance process before it can alter the rendered comparison.
Readers can use the Travel and mobility records hub for the parent subject and the business-card KYC and public records page for the separate boundary between issuer-held identity records and public business records. The airline and hotel identity-data retention page narrows the comparison to those six program families. These routes add context; they do not fill a missing cell, override a provider's scope, or alter the evidence in any table field.
How to read Unknown
- Unknown: Verified absence
- The captured authority was searched and shows no such rule or filing. No value is printed because the absence is the finding. The reason and the authority are printed beside the badge.
- Unknown: Not yet verified
- The captured sources did not settle this field yet. No value is printed, not even an earlier one. The reason is printed beside the badge, and an authority is linked only when one was supplied.
Frequently asked questions
What identity data do loyalty programs collect?
The answer differs by provider, program, event, jurisdiction, and revision. Each row's Identity data collected cell reports only the categories stated by that accepted first-party record.
When does a loyalty program verify an account or identity?
Verification is event-specific. The table reports only the login, recovery, support, account-access, account-change, linking, or other event established by the accepted provider cell.
How long do loyalty programs retain personal information?
Some accepted records state a duration, while others state a purpose-based or account-status criterion. The retention cell preserves the provider's category, trigger, exceptions, and scope without inventing a universal period.
Does a loyalty-program record prove that someone traveled?
No. A cited record may establish collection, a documented verification event, a retention criterion, a sharing or linkage relationship, or an account role; none of those facts alone proves physical presence or completed travel.