KYC and KYB Compliance Systems

KYC begins by resolving the person to whom the submitted information relates. The system must then determine whether the available evidence is authentic, current, internally consistent, and connected to the person presenting it.

Depending on the relationship, the evidence set may establish:

• legal name and date of birth;
• nationality, residence, and address;
• government or other recognized identifiers;
• the validity of identity documents;
• the connection between the document and its holder;
• the purpose and expected use of the relationship;
• source-of-funds or source-of-wealth information where required;
• sanctions, politically exposed person, adverse-information, or internal risk signals;
• the person’s authority to act for themselves, another person, or an organization.

These results do not produce a customer decision independently. A valid identity document may establish a name and document number without resolving whether the relationship is consistent with the institution’s risk appetite, whether the person is acting for another party, or whether further due diligence is required.

The required evidence and review depth should therefore follow the risk methodology established by the institution’s AML program structure, rather than a universal document checklist.

For a legal entity, KYB establishes both legal identity and operating context. The process resolves whether the organization exists, whether the available records describe the same entity, what activity it conducts, who ultimately owns or controls it, and which people may bind or instruct it.

A KYB record may include:

• legal name, legal form, and registration number;
• incorporation jurisdiction and status;
• registered and operating addresses;
• directors, officers, partners, trustees, or equivalent roles;
• stated and observed business activity;
• licenses or permissions where relevant;
• direct and indirect shareholders;
• beneficial owners and other control persons;
• authorized representatives and signatories;
• ownership percentages, voting rights, appointment rights, and other control mechanisms;
• the sources used to support each conclusion.

Even a current company record establishes only part of that picture. A registry entry may confirm incorporation and named officers while leaving indirect ownership, contractual control, nominee arrangements, or delegated authority unresolved.

Entity data therefore has to connect with person-level KYC. Completion means identifying the individuals behind the organization and establishing whether the person interacting with the institution holds the authority claimed.

A recurring control failure occurs when the system treats successful identity verification as proof of organizational authority.

These claims must remain distinct:

1. Identity: the individual is the person identified by the evidence.
2. Role: the individual holds a stated position in relation to the entity.
3. Authority: that role or a separate mandate permits the individual to perform the requested action.
4. Scope: the authority covers the relevant product, account, transaction, or instruction.
5. Validity: the authority remains current and has not been revoked or superseded.

A verified director, employee, adviser, or shareholder does not automatically have authority to open an account, appoint users, instruct payments, or change ownership information. The evidence supporting authority may come from constitutional documents, board resolutions, mandates, powers of attorney, account instructions, or other governance records.

Once the entity and its connected people have been assessed, the customer record needs to preserve the relationships between them. Separate verification results cannot show how ownership, control, management, representation, or delegated access combine in the approved relationship.

The record should show:

• which person is linked to which entity;
• whether the connection arises from ownership, control, management, representation, or delegated access;
• which source supports that relationship;
• when the evidence was obtained and last confirmed;
• which discrepancies remain unresolved;
• how each relationship affected the customer risk assessment;
• which restrictions or approval conditions apply.

Later changes then become traceable to the affected decision. A new beneficial owner, revoked mandate, expired credential, or altered corporate role can trigger a targeted reassessment, while unrelated evidence remains intact.

The wider ownership of policies, decision rights, escalation routes, and control standards belongs within compliance architecture. KYC and KYB apply those requirements to the individual customer relationship.

Three operations make up the core of identity proofing.

1. Identity resolution determines which real-world person the submitted attributes describe.
2. Evidence validation determines whether the document, credential, record, or issuing source is authentic, current, and suitable for the claim.
3. Identity verification determines whether the applicant is the person represented by the validated evidence.

Results can diverge. A consistent combination of name, date of birth, address, and government identifier may resolve an identity even when the submitted document fails authenticity checks. A genuine document may validate successfully while biometric comparison fails to connect it to the applicant. Strong biometric similarity can also sit inside a compromised session if manipulated media entered outside the approved capture channel, so no single result describes the integrity of the complete proofing process.

The record therefore separates the result of each operation:

• identity attributes resolved;
• evidence type and issuing source;
• authenticity and validity checks;
• connection between evidence and applicant;
• biometric or attended verification result;
• channel and device signals;
• unresolved discrepancies;
• assurance level reached;
• reviewer or system responsible for the conclusion.

Together, these results show what the process established and where uncertainty remains.

Each item of evidence should be connected to the claim it supports.

One source may support several claims, and one claim may require several sources. The institution should define which combinations provide sufficient assurance for the customer, product, channel, and risk level involved.

A successful document check establishes the result of that check. The customer decision still depends on the broader evidence set, relationship purpose, risk assessment, screening results, and applicable approval requirements.

A document may pass through several distinct checks:

• format and security features;
• machine-readable data;
• visible and encoded data consistency;
• document number and issuing authority;
• issue and expiry dates;
• signs of alteration;
• image substitution;
• template anomalies;
• duplicate use across identities;
• confirmation against an issuing or authoritative source;
• revocation, cancellation, or replacement status where available.

Source and method determine the weight of each result. Visual conformity to an expected template provides a different level of assurance from direct confirmation by an issuing authority, while a database match may confirm selected attributes without establishing possession of the underlying identity.

Method, source, result, and validation time remain attached to the evidence. A single pass or fail field would erase those differences.

Biometric controls usually address two different questions:

1. Does the submitted face or other biometric correspond to the identity evidence?
2. Was the biometric obtained from a live applicant through the expected interaction?

Face comparison, liveness analysis, attended video review, device signals, and challenge-response controls can contribute to these conclusions. Their value depends on capture quality, attack resistance, testing conditions, demographic performance, thresholds, and the way uncertain results enter manual review.

A presence result supports the integrity of the interaction. It does not independently establish the applicant’s identity, authority, customer risk, or right to use the requested product.

The decision record should retain:

• the biometric operation performed;
• reference and probe sources;
• confidence or outcome;
• applicable threshold;
• presentation-attack or presence result;
• reason for referral;
• manual review outcome;
• evidence retained or deliberately excluded under data-retention rules.

Between capture and verification lies a separate control boundary: the route by which evidence enters the service that validates or compares it.

Altered documents, synthetic portraits, prerecorded video, virtual-camera output, manipulated device streams, or forged media may be inserted after the apparent capture point. Downstream document and biometric checks can then receive credible-looking inputs that never passed through the expected live interaction.

The architecture distinguishes:

• presentation attacks, in which an artefact is shown to a genuine capture device;
• injection attacks, in which untrusted media or data is introduced into the technical workflow;
• forged media, in which images, video, audio, or identity evidence are created or materially altered;
• session substitution, in which evidence from one interaction is reused in another;
• human-assisted impersonation, in which several people or devices participate in the same onboarding attempt.

Relevant controls may include:

• trusted in-application capture;
• blocking or detecting virtual input sources;
• device and application integrity signals;
• signed or bound capture metadata;
• challenge-response interaction;
• comparison of visual, encoded, and source data;
• replay and duplicate detection;
• session binding;
• independent issuing-source checks;
• manual escalation for conflicting signals;
• monitoring of fraud outcomes after onboarding.

A liveness score covers only one part of this route. Effective remote proofing protects capture, transmission, comparison, decision, and evidence retention as one connected path.

The required strength of identity evidence should reflect the consequence of accepting the wrong person and the risks attached to the requested relationship.

Factors may include:

• product capabilities;
• payment or withdrawal limits;
• access to other people’s funds or data;
• ability to initiate irreversible instructions;
• delivery channel;
• customer geography;
• impersonation and synthetic-identity exposure;
• delegation or representative relationships;
• legal or regulatory requirements;
• availability of authoritative sources;
• opportunities to detect and contain later misuse.

This supports a tiered evidence model. Lower-risk and constrained relationships may use a narrower set of attributes and controls. Higher-risk relationships may require stronger evidence, source confirmation, attended verification, additional approval, or product restrictions.

The institution should define the permitted relationship at each assurance level. Identity proofing, product access, limits, monitoring intensity, and escalation should operate as connected controls rather than independent configurations.

Reusable digital identity changes how evidence may enter onboarding.

Instead of submitting a new image of the same document to every institution, a customer may present a digitally signed credential issued by a recognized authority or qualified provider. The credential can attest to specific attributes, such as name, date of birth, nationality, address, professional status, or the right to represent an organization.

This creates a different evidence chain:

Issuer → credential → holder presentation → relying party validation → customer decision

The relying institution must determine:

• who issued the credential;
• which attributes the issuer attested to;
• the assurance and verification process behind the credential;
• whether the credential remains valid;
• whether it has been revoked or superseded;
• whether the presenter is the legitimate holder;
• whether the requested attributes are sufficient for the relationship;
• how the credential maps into the institution’s own KYC controls.

A reusable credential can reduce repeated document collection and improve data integrity. The institution still owns the decision about evidence sufficiency, customer risk, screening, acceptance, and ongoing due diligence.

Digital credentials allow an institution to request a defined attribute or conclusion rather than a complete identity document.

Examples include:

• confirmation that the customer exceeds an age threshold;
• verified legal name;
• confirmed residential jurisdiction;
• professional or licensing status;
• representation of a legal entity;
• validity of an identifier;
• authority attached to a corporate role.

This approach can reduce unnecessary data collection while strengthening the provenance of the attributes received. It also requires precise control design: the relying institution must know whether it needs the underlying value, a threshold result, the identity of the issuer, the date of issuance, or proof that the credential remains current.

Selective disclosure changes the amount of data exchanged. It does not change the institution’s responsibility to obtain the information necessary for its compliance objective.

Digital onboarding depends on four different conclusions:

• Identity establishes which person or entity is involved.
• Attribute establishes a defined fact associated with that subject.
• Authentication establishes control of a credential associated with an enrolled subject.
• Authority establishes the right to act for another person or organization.

Successful authentication may coexist with outdated identity attributes. A credential may confirm employment or directorship while leaving transactional authority unresolved. A valid organizational identifier may resolve a company without identifying its beneficial owners.

Keeping these conclusions separate allows each downstream decision to draw on the evidence that actually supports it.

Portable credentials can improve the initial evidence set, but the customer relationship continues to change after onboarding.

The institution still needs to detect:

• credential expiry or revocation;
• changed names or addresses;
• new ownership or control;
• altered corporate roles;
• terminated representation;
• changes in risk or product use;
• activity inconsistent with the original profile;
• new sanctions, PEP, adverse-information, or internal signals.

Reusable identity therefore changes how evidence is supplied. Ongoing due diligence determines whether that evidence and the resulting customer decision remain valid.

The customer risk profile combines information about the subject, the requested relationship, and the way that relationship is expected to operate.

Common factor groups include:

These dimensions should not operate as an unstructured list. Each factor should connect to a defined rationale and, where appropriate, a specific control response.

For example:

• complex ownership may require deeper beneficial-ownership analysis;
• remote onboarding may require stronger evidence-channel controls;
• elevated geographic exposure may require additional approval or monitoring;
• inconsistent business information may require independent corroboration;
• a high-capability product may require stronger identity assurance and lower tolerance for unresolved evidence;
• activity outside the expected profile may trigger event-driven review.

A customer may present elevated inherent risk because of its structure, location, product use, business activity, or connected persons.

The institution then applies controls intended to reduce or manage that exposure.

These controls may include:

• additional evidence;
• source confirmation;
• enhanced screening;
• senior approval;
• account or product restrictions;
• lower transaction limits;
• narrower geographic access;
• shorter review intervals;
• closer transaction monitoring;
• mandatory case escalation;
• additional reporting or documentation requirements.

The resulting assessment should distinguish between:

• inherent risk: exposure before the relevant controls are applied;
• control response: measures imposed to address that exposure;
• residual risk: the risk remaining after the controls are considered;
• acceptance decision: whether the residual risk falls within the institution’s approved boundaries.

Without this distinction, a relationship may appear low risk only because the rating process has already assumed that controls will work.

Every material risk factor needs an evidence path that a later reviewer can reproduce.

That path includes:

• factor definition;
• data source;
• observed value;
• date obtained;
• applicable rule or weighting;
• reviewer adjustment;
• reason for adjustment;
• resulting contribution to the classification.

Free-form judgment remains useful where customer structures or business models do not fit standardized categories. The rationale turns that judgment into an auditable part of the decision.

Unexplained overrides break the evidence path. The resulting score may look precise while no longer describing the customer record beneath it.

Where the institution has established lower risk and the applicable framework permits reduced measures, simplified due diligence adjusts the depth of the process.

Simplification may affect:

• the amount of evidence collected;
• the method of verification;
• the depth of ownership analysis;
• approval level;
• review frequency;
• monitoring intensity.

Customer identification, risk assessment, sanctions controls, and ongoing due diligence remain part of the relationship.

The simplified record documents:

• why the lower-risk conclusion applies;
• which measures were reduced;
• which minimum controls remain mandatory;
• which changes would remove eligibility for simplified treatment.

New information that changes those conditions moves the relationship into standard or enhanced measures.

Standard customer due diligence establishes the baseline evidence and assessment required for customers within the institution’s ordinary risk range.

The process typically includes:

• identification of the customer;
• verification from reliable sources;
• understanding the purpose and intended nature of the relationship;
• identification and verification of beneficial owners where applicable;
• screening of relevant persons and entities;
• customer risk classification;
• approval under the applicable authority;
• creation of an expected activity profile;
• ongoing monitoring and periodic or event-driven review.

The baseline should be defined by customer and relationship type rather than a single universal checklist.

An individual payment account, a regulated financial institution, a small private company, and a multi-layer international group create different evidence and control requirements even when all receive a standard classification.

Enhanced due diligence applies when the relationship presents higher risk, material uncertainty, or a condition that requires deeper review.

Possible triggers include:

• complex or opaque ownership;
• unexplained intermediate entities;
• higher-risk jurisdictions;
• politically exposed persons;
• significant adverse information;
• unusual business models;
• cash-intensive activity;
• high-risk products or payment capabilities;
• private investment structures;
• nominee or trust relationships;
• source-of-funds or source-of-wealth concerns;
• non-face-to-face onboarding with elevated fraud exposure;
• contradictions between customer declarations and independent sources;
• expected activity that is difficult to corroborate;
• prior regulatory, criminal, or internal compliance concerns.

Enhanced due diligence should respond to the identified risk.

Measures may include:

• additional identity or corporate evidence;
• independent confirmation from authoritative sources;
• deeper ownership and control analysis;
• verification of source of funds;
• assessment of source of wealth;
• corroboration of business activity;
• review of key counterparties;
• additional adverse-information research;
• senior-management approval;
• legal or specialist review;
• product, geography, channel, or transaction restrictions;
• more frequent customer review;
• intensified monitoring.

A request for more documents does not by itself constitute enhanced due diligence. Each additional measure should address a defined uncertainty or risk.

Source of funds and source of wealth answer different questions.

• Source of funds concerns the origin of the money or assets used in a specific relationship or transaction.
• Source of wealth concerns how the person or organization accumulated its broader economic resources.

The evidence required depends on the customer, transaction, product, and risk.

Possible sources include:

• salary or business income;
• sale agreements;
• audited accounts;
• tax records;
• investment statements;
• inheritance records;
• financing agreements;
• dividend records;
• corporate distributions;
• asset ownership and disposal records;
• transaction history;
• independently verified business activity.

The review should assess whether the explanation is plausible, sufficiently evidenced, and consistent with the customer profile.

A document may prove that funds moved from one account without explaining how they were originally generated. The control objective should determine how far the evidence chain must extend.

Sanctions, PEP, adverse-information, and internal screening results enter the customer risk assessment in different ways.

A confirmed sanctions prohibition may prevent the relationship or require legally defined action. A PEP match may trigger enhanced due diligence and approval requirements. Adverse information may require an assessment of relevance, credibility, recency, and connection to the customer.

The KYC/KYB system should preserve:

• subject screened;
• source or list;
• matching result;
• reviewer disposition;
• supporting evidence;
• date;
• impact on risk;
• required follow-up.

Detailed matching logic and alert resolution belong to sanctions screening. The customer risk profile should receive the final relevant conclusion and remain capable of responding to future screening changes.

Adverse information should not be treated as a binary field.

A useful assessment considers:

• identity match;
• source credibility;
• date and recency;
• nature of the allegation or event;
• legal or regulatory outcome;
• connection to the proposed relationship;
• pattern across multiple sources;
• evidence of remediation;
• materiality to the institution’s control objective.

The record should distinguish allegations, investigations, enforcement findings, convictions, dismissals, and unverified repetition across secondary sources.

The decision should explain how the information affected risk, due diligence, restrictions, approval, or rejection.

Expected activity connects onboarding information with later transaction monitoring.

The profile may describe:

• transaction types;
• expected volumes;
• average and maximum values;
• currencies;
• jurisdictions;
• counterparties;
• funding sources;
• payment purposes;
• cash or digital-asset exposure;
• seasonality;
• account turnover;
• use of third parties;
• expected changes during the relationship.

This information should be specific enough to support later comparison without pretending that customer activity will remain mechanically fixed.

The objective is to establish a credible operating range. Material departures can then trigger review, investigation, or an updated risk classification.

The feedback path between expected and observed activity connects KYC/KYB with transaction monitoring.

The classification should determine operational consequences.

These responses should remain configurable by customer type and relationship.

A high-risk customer does not necessarily produce the same control response across every product. The institution may accept one constrained relationship while declining another with broader payment, custody, credit, or transfer capabilities.

Acceptance does not need to be entirely binary.

The institution may approve a relationship with conditions such as:

• lower limits;
• restricted products;
• permitted jurisdictions;
• prohibited counterparties;
• no third-party funding;
• no cash activity;
• no delegated users;
• additional approval for defined transactions;
• enhanced monitoring;
• evidence required before wider access;
• an accelerated review date.

Restrictions should be explicit, technically enforceable, visible to relevant operating systems, and linked to the customer decision.

A restriction recorded only in narrative notes may fail when product, payment, or operations teams cannot enforce it.

Approval authority follows the customer state, the residual risk, and the type of exception presented.

Relevant conditions may include:

• customer risk;
• product;
• geography;
• unresolved evidence;
• PEP status;
• adverse information;
• ownership complexity;
• source-of-funds or source-of-wealth concerns;
• policy exception;
• requested restriction;
• residual risk.

The decision record identifies:

• decision maker;
• authority level;
• decision date;
• evidence reviewed;
• conditions imposed;
• expiry or review point;
• dissent or escalation where applicable.

Senior approval therefore records an informed acceptance of defined residual risk. It is part of the decision logic, not a procedural signature added after the analysis.

Automated and rules-based models can improve consistency and scale. Weak governance turns the same factors, thresholds, weights, and overrides into a source of hidden decision error.

A controlled risk model has:

• defined purpose;
• documented factors;
• justified weights;
• controlled data sources;
• version history;
• validation;
• testing against actual outcomes;
• override rules;
• monitoring for drift;
• change approval;
• fallback procedures;
• traceable outputs.

Missing data also carries its own state. A blank ownership field, unavailable registry result, or failed screening source cannot contribute the same result as confirmed low-risk information.

The wider methodology, governance, testing, and escalation framework belongs within the institution’s AML program.

A complete due-diligence record shows:

1. who or what was assessed;
2. what relationship was requested;
3. which risk factors were identified;
4. which evidence supported them;
5. which measures were applied;
6. which issues remained unresolved;
7. who approved the decision;
8. which restrictions were imposed;
9. how the relationship should be monitored;
10. when or why it should be reviewed again.

This record links the initial assessment to ongoing monitoring, case management, regulatory examination, and future remediation.

Its value becomes operational downstream: systems can control access, apply limits, prioritize alerts, set review frequency, and detect material change from the same approved classification.

Customer approval reflects the evidence and risk conditions established at a particular time.

Those conditions may change because:

• the customer’s identity attributes change;
• a company changes legal status;
• ownership or control changes;
• a representative gains or loses authority;
• the customer adds a product or jurisdiction;
• business activity develops in a new direction;
• observed transactions depart from the expected profile;
• screening produces a new result;
• evidence expires or loses authority;
• policy or regulatory requirements change.

Ongoing due diligence determines whether each change affects the validity of the existing decision.

The system should retain both:

• the current approved state of the relationship;
• the history of evidence, assessments, restrictions, and decisions that produced it.

This allows reviewers to distinguish a stable relationship from one whose apparent approval depends on outdated or unresolved information.

Periodic review sets the latest point at which the institution must actively reconsider the customer record.

The review interval may reflect:

• customer risk;
• customer and entity type;
• ownership complexity;
• product capability;
• geography;
• quality and durability of the evidence;
• expected activity;
• screening exposure;
• policy requirements;
• unresolved conditions from the previous decision.

A periodic review may assess:

• identity and contact information;
• legal-entity status;
• beneficial ownership and control;
• directors and authorized representatives;
• business activity;
• products and services used;
• expected and observed activity;
• source of funds or wealth where relevant;
• screening results;
• customer risk classification;
• active restrictions;
• evidence expiry;
• open exceptions or cases.

The review does not need to reproduce every onboarding action mechanically. Its scope should reflect the current risk, the age and reliability of existing evidence, and the changes observed since the previous decision.

AMLA’s June 2026 draft guidelines distinguish periodic reviews from updates triggered by specific events and propose a risk-based approach to the frequency, depth, and scope of customer-information updates. The consultation remains open until 3 September 2026. (AMLA Draft Guidelines on Ongoing Monitoring)

An event-driven review begins when new information may materially affect the customer profile or the validity of a previously established claim.

The trigger should identify:

1. what changed;
2. which customer or connected party is affected;
3. which claim or risk factor may require reassessment;
4. which evidence needs updating;
5. whether the current relationship can continue during the review;
6. which reviewer or function owns the response.

This creates a targeted review rather than an undifferentiated request to repeat the complete onboarding process.

A material change to one beneficial owner may require ownership recalculation, person-level KYC, screening, risk reassessment, and approval. It may leave unrelated identity and entity evidence intact.

AMLA’s current draft identifies changes in identity, legal status, ownership, directors, authorized representatives, activity, behaviour, transaction patterns, adverse information, PEP status, financial position, products, jurisdictions, and counterparties as potential triggers for customer review and risk reassessment. (AMLA Draft Guidelines on Ongoing Monitoring)

Material changes can enter the institution through several routes:

• customer declarations;
• customer-service and relationship-management interactions;
• company and beneficial-ownership registries;
• credential-status or revocation services;
• screening platforms;
• transaction-monitoring alerts;
• payment and account operations;
• fraud systems;
• internal investigations;
• regulatory or public-authority notices;
• external commercial data;
• periodic data matching;
• partner or sponsor-bank notifications.

Each source needs a defined route into the customer record: direct update, verification workflow, challenge, or review trigger.

A registry change may generate a signal that requires review rather than automatically rewriting approved ownership data. A customer declaration may update a contact field immediately while routing a change in beneficial ownership through verification and approval.

The system should preserve:

• source of the trigger;
• time detected;
• data received;
• affected customer and connected persons;
• materiality assessment;
• workflow created;
• interim controls;
• final disposition.

Together, these fields convert a raw data change into a controlled review state with a visible owner and outcome.

Periodic review provides a scheduled backstop. Event-driven review responds to material change when it occurs.

The combined model can be expressed as:

Periodic review sets the maximum review horizon. Events determine when the customer must be reassessed earlier.

A calendar-only model can leave a significant ownership, authority, or activity change unreviewed until the next scheduled date.

A trigger-only model can leave a customer record untouched when the institution fails to detect changes or when evidence gradually loses relevance.

The institution therefore needs both:

• scheduled review coverage;
• reliable detection of material events.

The customer profile created during onboarding establishes the expected purpose and operating range of the relationship.

It may include:

• products and capabilities;
• expected transaction values and frequency;
• currencies;
• jurisdictions;
• funding sources;
• counterparty types;
• payment purposes;
• business activity;
• seasonality;
• anticipated account turnover;
• use of cash, intermediaries, third parties, or digital assets;
• expected changes as the relationship develops.

Transaction monitoring compares observed transactions and activity with this profile and with other risk indicators.

A material deviation can indicate:

• the original profile was incomplete;
• the customer’s activity changed legitimately;
• a new product or market was added;
• another person controls or uses the relationship;
• the stated business purpose no longer explains the activity;
• the customer risk classification requires adjustment;
• enhanced due diligence or investigation is required.

The monitoring output should therefore be capable of updating KYC/KYB rather than ending as an isolated transaction alert.

The relationship between customer due diligence and activity monitoring operates in both directions.

KYC and KYB provide:

• verified customer and entity identity;
• ownership and control relationships;
• business purpose;
• product scope;
• expected activity;
• risk classification;
• restrictions;
• relevant connected persons.

Transaction and activity monitoring provide:

• observed customer behaviour;
• deviations from expected activity;
• new counterparties and jurisdictions;
• source and destination of funds;
• product-use changes;
• linked relationships;
• patterns requiring further assessment.

The complete loop is:

Customer evidence → risk profile → expected activity → observed activity → discrepancy → reassessment → updated customer decision

AMLA’s 2026 draft guidelines explicitly connect monitoring outputs with updates to customer due-diligence information and customer risk classification. They also state that customer profiles used for monitoring should derive from verified CDD information, including the purpose and intended nature of the relationship and expected transactions or activities. (AMLA Draft Guidelines on Ongoing Monitoring)

A transaction or activity alert may identify behaviour that requires review. The KYC/KYB system must determine what the behaviour means for the customer record.

The review may conclude that:

• the activity fits an existing legitimate profile;
• the expected profile requires updating;
• the customer added a new product, market, or counterparty type;
• additional source-of-funds evidence is required;
• the risk classification should increase;
• a restriction should be imposed;
• enhanced due diligence is required;
• the issue belongs in investigation;
• the relationship remains outside approved boundaries.

The final disposition should return to both systems.

Transaction monitoring receives the updated profile or restriction. KYC/KYB receives the evidence and rationale produced by the review.

A review should identify which parts of the customer record require updating.

Possible review scopes include:

• one identity attribute;
• one expired credential;
• one representative’s authority;
• the complete ownership structure;
• one beneficial owner;
• customer risk classification;
• expected activity;
• source of funds;
• screening disposition;
• product eligibility;
• the entire relationship.

The scope decision should consider:

• nature of the trigger;
• materiality;
• age of existing information;
• reliability of the source;
• customer risk;
• connected claims;
• product capabilities;
• prior discrepancies;
• recent investigations or alerts.

The resulting scope preserves validated evidence and concentrates review on the changed risk.

Evidence can lose value through formal expiry, source changes, changed circumstances, or increasing distance from the original verification date.

The system should distinguish:

• document expiry — the instrument reached its stated expiry date;
• credential revocation — the issuer withdrew its validity;
• source staleness — the underlying record has not been refreshed;
• claim change — the customer’s current information differs from the evidence;
• control obsolescence — the evidence no longer meets the institution’s current standard;
• decision impact — the expired or changed evidence affects an active relationship.

A document expiry should generate a defined assessment rather than a uniform response across every customer and product.

The system may require:

• immediate replacement;
• replacement at the next customer interaction;
• replacement during the next scheduled review;
• confirmation through another authoritative source;
• temporary restriction;
• no additional action where the evidence continues to support a stable historical claim and current verification comes from another source.

The recorded rationale shows why the evidence remained acceptable, required replacement, or changed the active customer decision.

Beneficial-ownership information should be updated when the institution identifies a relevant change, detects facts that challenge the reliability of the existing record, or reaches a review point defined by its risk-based procedures.

The update may require:

• customer confirmation;
• current registry information;
• revised shareholder records;
• new constitutional or governance documents;
• recalculation of direct and indirect ownership;
• analysis of new control rights;
• KYC and screening of newly identified persons;
• removal or historical closure of former relationships;
• customer-risk reassessment;
• updated approval.

In February 2026, FinCEN granted covered U.S. financial institutions relief from identifying and verifying a legal-entity customer’s beneficial owners every time that existing customer opens another account. The institution must still perform the process at the first account opening, when facts reasonably challenge the reliability of previously obtained information, and when its risk-based ongoing CDD procedures require an update. (FinCEN CDD Exceptive Relief Order FIN-2026-R001)

This illustrates a wider operating distinction:

A new product event may trigger review. The review should determine which customer information requires updating rather than automatically repeating every previous control.

An existing customer may request:

• another account;
• higher limits;
• cross-border access;
• a new payment rail;
• additional users;
• credit;
• custody;
• digital-asset capability;
• new currencies;
• access through an API or platform;
• a product with greater transaction finality or fraud exposure.

The first question is whether the existing decision covers the new relationship.

The review may consider:

• whether identity assurance remains sufficient;
• whether ownership information remains current;
• whether representatives have authority for the new product;
• whether the product changes customer risk;
• whether new source information is required;
• whether restrictions remain enforceable;
• whether monitoring requires recalibration;
• whether another approval authority applies.

Product expansion therefore creates a distinct decision state instead of inheriting approval from an unrelated relationship.

A customer may remain active while a periodic or event-driven review is pending.

The institution should define the operating state during that period.

Possible responses include:

• continuation without additional restriction;
• prevention of new product access;
• lower transaction limits;
• restriction of specific jurisdictions or counterparties;
• suspension of new users;
• requirement for additional approval;
• enhanced monitoring;
• temporary account suspension;
• controlled relationship exit.

Materiality determines the interim operating state.

An expired address document may have a different operational effect from an unidentified new beneficial owner, a revoked mandate, or a sanctions concern.

The record should show:

• issue under review;
• interim decision;
• authority approving it;
• restrictions imposed;
• effective date;
• deadline;
• escalation path.

These fields keep the temporary operating condition aligned with the unresolved customer risk until review reaches a final decision.

Sanctions, PEP, adverse-information, and internal screening continue after onboarding.

The system should determine:

• which customers and connected persons require rescreening;
• which sources and lists apply;
• how frequently or continuously screening occurs;
• how changed identity data reaches the screening system;
• how new matches return to the customer record;
• how dispositions affect risk and access;
• how former and historical connected persons are treated.

Each new result carries the subject screened, matching evidence, reviewer disposition, risk effect, action taken, and date into the customer record.

Detailed matching and alert controls remain within sanctions screening. KYC/KYB owns the effect of the resolved result on the customer decision.

Remediation addresses customer records that no longer provide sufficient evidence for the current relationship.

Common remediation drivers include:

• historical onboarding standards below the current requirement;
• incomplete ownership data;
• missing connected-person KYC;
• expired or unavailable evidence;
• unsupported risk ratings;
• inconsistent records across systems;
• undocumented authority;
• missing decision rationale;
• new regulatory or policy requirements;
• data lost or altered during migration;
• vendor results without reproducible source evidence;
• monitoring findings that were never returned to the customer profile.

Remediation should identify the control gap and the decision affected by it.

A complete remediation item should state:

1. which claim or record is deficient;
2. how the issue was identified;
3. which customers and relationships are affected;
4. the risk and materiality;
5. the evidence or review required;
6. interim operating conditions;
7. the responsible owner;
8. the target completion date;
9. escalation requirements;
10. the closure decision.

Large remediation programs often contain customers with very different levels of exposure.

Prioritization may consider:

• customer risk;
• product capability;
• transaction activity;
• ownership opacity;
• sanctions or PEP exposure;
• evidence gap;
• age of the record;
• unresolved monitoring alerts;
• relationship value and operational complexity;
• regulatory commitment;
• ability to impose interim controls;
• consequence of an incorrect customer decision.

A prioritized program may address first:

• customers with unidentified beneficial owners;
• customers using high-capability products;
• relationships linked to material transaction-monitoring findings;
• high-risk customers with unsupported ratings;
• customers whose authority or identity remains uncertain;
• relationships with active regulatory or investigative concerns.

The program should retain a documented rationale for sequencing and for any accepted delay.

Collecting a replacement document does not complete remediation by itself.

Closure requires the institution to determine:

• whether the missing claim has been established;
• whether new information changes risk;
• whether screening must be repeated;
• whether ownership or authority relationships changed;
• whether restrictions remain necessary;
• whether the customer can continue;
• whether the decision requires new approval;
• whether connected systems received the updated result.

Possible remediation outcomes include:

• current approval confirmed;
• risk classification updated;
• enhanced due diligence completed;
• new restrictions imposed;
• product access reduced;
• relationship suspended;
• relationship exited;
• issue transferred to investigation.

Formal investigation, exception disposition, and documented closure should connect to compliance case management. Program-level remediation commitments, examination responses, and evidence production connect to regulatory operations.

A remediation or periodic-review program may require outreach to a large customer population.

The operating design should control:

• population definition;
• prioritization;
• required evidence by customer type;
• communication sequence;
• secure evidence submission;
• response tracking;
• duplicate requests;
• customer-service escalation;
• deadlines;
• non-response treatment;
• quality review;
• final decision.

Customer outreach should request evidence linked to a specific control gap.

A generic demand for every available corporate or identity document increases operational volume while making it harder to determine whether the identified deficiency was resolved.

Operational measures may include:

• reviews due and overdue;
• time from trigger to assessment;
• aged unresolved triggers;
• review completion by risk tier;
• evidence-expiry exposure;
• customers operating under temporary conditions;
• ownership changes awaiting verification;
• screening results awaiting disposition;
• remediation population and closure rate;
• repeated requests caused by fragmented records;
• risk changes following review;
• restrictions applied or removed;
• exits resulting from ongoing review;
• quality defects and reopened decisions.

Metrics should distinguish workflow completion from control effectiveness.

A completed review with unresolved ownership, unexplained activity, or an unsupported risk decision remains a control concern.

Ongoing due diligence connects every stage of the customer lifecycle:

Approved customer record → scheduled and continuous monitoring → material change detected → affected claims reviewed → risk reassessed → decision updated → restrictions and monitoring recalibrated

The operating system remains effective when identity, ownership, authority, screening, activity, risk, and decision data can update one another.

KYC and KYB then function as a maintained control over the customer relationship rather than a record of checks completed at onboarding.

A service provider may execute a KYC or KYB task without owning the compliance conclusion produced from it.

Examples include:

• an identity provider validates a document;
• a biometric service returns a comparison result;
• a registry service resolves a legal entity;
• a KYB platform constructs an ownership graph;
• a screening provider generates an alert;
• an outsourced operations team reviews evidence;
• a fintech collects customer information;
• a sponsor bank approves or rejects a defined customer category.

The operating model should distinguish:

• task execution: who performs the activity;
• control ownership: who defines the required outcome;
• decision authority: who may accept, restrict, reject, or exit the customer;
• oversight: who monitors whether the process remains effective;
• evidence custody: who retains the records needed to demonstrate the decision.

One participant may hold several roles. Any overlap remains explicit because task execution, control ownership, decision authority, oversight, and evidence custody produce different accountability outcomes.

This table describes common patterns rather than a universal legal allocation. The actual model depends on the product, jurisdiction, contracts, licenses, and participating institutions.

Accountability sits with the institution responsible for the customer relationship. It must be able to explain:

• which customer was accepted;
• which KYC and KYB requirements applied;
• which parties performed each task;
• which evidence supported the decision;
• which exceptions were accepted;
• who had authority to approve the relationship;
• which restrictions were imposed;
• how the customer will be monitored and reviewed;
• how failures by a provider are detected and addressed.

A vendor completion flag cannot answer those questions.

Evidence, results, rationale, and workflow history therefore remain available to the accountable institution in a form that reproduces the complete customer decision.

In a sponsor-bank arrangement, the fintech may operate much of the customer-facing and technical process while the bank retains regulated responsibilities and defined decision rights.

The allocation may cover:

• customer disclosures and consent;
• required identity and entity data;
• document and biometric methods;
• prohibited customer types;
• risk-rating methodology;
• sanctions and PEP screening;
• beneficial-ownership analysis;
• enhanced due diligence;
• exception approval;
• customer acceptance;
• restrictions and limits;
• ongoing monitoring;
• periodic review;
• remediation;
• complaint handling;
• regulatory reporting;
• examination evidence.

A weak operating model uses general statements such as “the fintech performs KYC” or “the bank oversees compliance.”

A controlled model identifies the exact task, standard, evidence, decision right, service level, escalation path, and record owner.

The wider allocation of regulated and operational responsibility belongs to bank–fintech compliance responsibility. The product, account, ledger, and sponsor-bank structure around these relationships is addressed within the Banking-as-a-Service operating model.

The policy owner defines the customer-due-diligence requirements that every participant and system applies.

Those requirements cover:

• customer types in scope;
• required evidence;
• source hierarchy;
• beneficial-owner and control-person definitions;
• screening requirements;
• risk factors;
• due-diligence levels;
• approval authority;
• prohibited relationships;
• exception rules;
• review intervals;
• material-change triggers;
• remediation standards;
• record-retention requirements.

A vendor workflow may encode this logic, but the effective policy remains under institutional control. Material configuration changes therefore require the same owner and approval path as the written standard.

The customer-facing organization often collects identity, business, ownership, and relationship information.

Its responsibilities may include:

• presenting accurate questions;
• collecting required declarations;
• obtaining consent;
• providing secure submission channels;
• validating mandatory fields;
• preventing inconsistent or incomplete applications from advancing;
• informing the customer about outstanding requirements;
• preserving the relationship between the applicant, entity, and connected persons.

Poor data collection can weaken every downstream control.

Examples include:

• ownership percentages that do not total correctly;
• representatives recorded without corporate roles;
• legal and trading names mixed together;
• missing jurisdiction information;
• beneficial owners stored as free text;
• documents detached from the claims they support;
• new product requests that bypass customer reassessment.

The party controlling the interface should therefore follow the evidence and data model defined by the control owner.

A verification provider defines the boundary of its service through:

• the operation performed;
• supported documents, credentials, jurisdictions, and sources;
• checks included and excluded;
• outcome meanings;
• confidence or quality indicators;
• technical and data limitations;
• retention and deletion practices;
• service dependencies;
• change-notification procedures;
• evidence available for review.

A narrow verification operation remains one input to KYC or KYB unless the provider actually performs and owns the complete system.

Each provider output then maps to a specific claim, evidentiary result, and control decision.

An outsourced reviewer may examine evidence, resolve alerts, identify missing information, and prepare recommendations.

The operating agreement sets:

• reviewer qualifications;
• applicable policies;
• access to source evidence;
• permitted decisions;
• cases requiring escalation;
• quality-assurance requirements;
• productivity and aging expectations;
• evidence and rationale standards;
• handling of conflicts of interest;
• supervision;
• data protection;
• business-continuity procedures.

Review capacity does not compensate for unclear authority.

The reviewer’s permitted outcome is explicit: establish a claim, assign risk, approve an exception, accept a customer, or recommend an outcome for another authority.

Defined customer states and risk conditions determine who may decide.

The authority model may specify who may:

• accept a standard-risk customer;
• approve enhanced due diligence;
• resolve an ownership discrepancy;
• accept alternative evidence;
• override a risk rating;
• approve a PEP relationship;
• permit a policy exception;
• impose or remove restrictions;
• suspend access;
• reject an application;
• exit an active customer;
• close remediation.

Authority may depend on:

• customer type;
• risk;
• product;
• jurisdiction;
• ownership complexity;
• screening result;
• exception category;
• residual uncertainty;
• requested capability.

The customer record retains the approver, authority level, decision date, rationale, and applicable conditions. Without that record, execution can be traced while formal ownership of the decision remains unclear.

Across a distributed operating model, material evidence may sit in several systems and organizations.

A controlled model identifies where the following records are held:

• customer declarations;
• identity documents and credentials;
• biometric or presence results;
• registry data;
• ownership graphs;
• authority documents;
• screening alerts and dispositions;
• risk factors and ratings;
• enhanced-due-diligence evidence;
• case history;
• approvals;
• restrictions;
• review triggers;
• remediation records;
• audit events.

The party accountable for the customer decision requires timely access for:

• ongoing review;
• investigations;
• quality testing;
• complaints;
• regulatory examination;
• legal requests;
• provider migration;
• relationship exit.

That access survives termination of a vendor or partner relationship for the required retention period. Otherwise, formal accountability remains with an institution that can no longer produce the evidence behind its decisions.

Oversight should test whether the provider’s activities continue to satisfy the institution’s control requirements.

Relevant oversight may include:

• service-level monitoring;
• sample-based quality review;
• outcome testing;
• false-acceptance and referral analysis;
• review of overrides;
• evidence completeness;
• data-source coverage;
• model and rule changes;
• security and access controls;
• operational incidents;
• customer complaints;
• remediation caused by provider failures;
• subcontractor changes;
• business-continuity testing.

Oversight concentrates on the control result as well as processing time.

A provider can meet its processing target while producing incomplete ownership analysis, inconsistent decisions, or weak evidence trails.

Quality assurance determines whether the process was performed correctly under the applicable policy.

A review may examine:

• correct customer and entity resolution;
• required evidence obtained;
• source reliability;
• ownership and control analysis;
• connected-person KYC;
• screening disposition;
• risk classification;
• enhanced-due-diligence measures;
• approval authority;
• restrictions;
• review triggers;
• decision rationale;
• record completeness.

The quality function should distinguish:

• reviewer error;
• unclear policy;
• workflow defect;
• data-source limitation;
• vendor failure;
• system configuration issue;
• training gap;
• deliberate override;
• isolated and systemic defects.

The resulting response addresses the actual cause; otherwise, every defect returns to operations as the same generic correction.

Escalation should transfer a defined decision question with the supporting evidence.

A controlled escalation includes:

• customer and relationship;
• issue identified;
• policy or control affected;
• sources reviewed;
• unresolved evidence;
• risk and materiality;
• interim restrictions;
• decision required;
• deadline;
• responsible recipient.

Common escalation paths include:

• fintech operations to fintech compliance;
• fintech compliance to sponsor bank;
• vendor review team to institutional compliance;
• first-line operations to investigations;
• compliance to legal;
• customer review to regulatory operations;
• provider incident to third-party risk and senior management.

Without a defined issue and requested decision, the escalation changes queues but leaves authority unresolved.

A provider or partner incident can affect active onboarding, existing customer records, or both.

Possible failures include:

• verification outage;
• incorrect document results;
• missing screening coverage;
• stale registry data;
• ownership-calculation defect;
• unauthorized access;
• lost evidence;
• incorrect risk scores;
• incomplete transfer of restrictions;
• unreported model change;
• inability to reproduce prior decisions.

The response determines:

1. which control failed;
2. which customers and decisions may be affected;
3. whether activity should be restricted;
4. which alternative process applies;
5. whether historical review is required;
6. which participant owns customer communication;
7. which participant owns regulatory communication;
8. how evidence and decisions will be corrected;
9. how the issue will be prevented or detected earlier.

Once customer acceptance, restrictions, or monitoring outcomes may have changed, the event is a compliance-control incident as well as a technical service problem.

Changes to KYC and KYB processes may originate from any participant.

Examples include:

• new policy requirements;
• revised beneficial-ownership definitions;
• new document support;
• changed verification models;
• screening-list changes;
• new risk factors;
• vendor API changes;
• new products;
• altered sponsor-bank requirements;
• updated customer journeys;
• additional jurisdictions;
• revised review intervals.

The change process should identify:

• control objective affected;
• policy owner;
• systems and providers involved;
• customer populations affected;
• testing required;
• approval authority;
• implementation date;
• monitoring after release;
• need for historical remediation.

Updating one platform does not complete the change. Completion arrives only when every participant and downstream system uses the same effective rule and decision output.

Responsibility for customer communication should be explicit.

Communication may include:

• initial evidence requests;
• explanation of missing information;
• secure submission instructions;
• periodic review outreach;
• material-change confirmation;
• remediation requests;
• notification of restrictions;
• rejection or exit communication;
• complaint handling.

The communication owner should receive enough decision context to request the correct evidence without disclosing restricted internal information.

Fragmented ownership can create repeated requests from the fintech, bank, vendor, and operations team for the same documents.

A shared evidence and workflow record reduces duplication and helps ensure that customer responses reach the correct decision process.

During examination or regulatory review, the responsible institution needs evidence of:

• the end-to-end operating model;
• allocation of tasks and authority;
• policies applied;
• provider oversight;
• customer evidence;
• risk and decision records;
• exception handling;
• quality testing;
• identified defects;
• remediation;
• governance of process changes.

A contract stating that a provider performs KYC establishes an allocation, not the effectiveness of the control.

Examination evidence shows how required activities are verified, how defects are detected, and how the final customer decision remains under controlled authority. Program-level evidence production, regulatory commitments, and remediation tracking belong within regulatory operations.

Recurring gaps include:

1. Collection without evidence ownership
   One party gathers documents, while no participant retains the complete evidentiary record.

2. Verification without interpretation
   A provider returns results, but the institution has not defined how those results affect acceptance.

3. Review without decision authority
   Operations complete analysis but cannot resolve exceptions or obtain timely approval.

4. Approval without operational enforcement
   Restrictions are accepted but never transmitted to account or payment systems.

5. Monitoring without customer reassessment
   Activity alerts remain separate from the KYC/KYB customer record.

6. Outsourcing without reproducibility
   The institution cannot reconstruct decisions after a vendor or service change.

7. Oversight without outcome testing
   Provider performance is measured through volume and speed while control quality remains untested.

8. Change without coordinated implementation
   Policy, vendor workflow, risk model, and downstream systems use different versions of the requirement.

9. Escalation without ownership
   Cases move between participants without a defined decision maker.

10. Shared responsibility without a final accountable party
    Each participant performs a task, but no institution can explain the complete customer decision.

A responsibility matrix should connect each material activity to execution, approval, oversight, and evidence ownership.

The exact allocation may differ. Every row should still have an identified owner.

KYC and KYB may operate across many institutions, vendors, and systems. The final customer decision still needs one connected line of evidence and authority.

The governing principle is:

Execution may be distributed. Evidence, authority, escalation, and accountability must remain connected to one controlled customer decision.

Under a strong operating model, every participant knows what it performs, what it does not decide, where evidence is held, when escalation begins, and which institution remains accountable for the relationship. Shared execution then produces one controlled outcome instead of a collection of completed tasks.

Compliance architecture provides the upstream governance for policies, roles, decision rights, escalation, testing, and evidence across the compliance function.

At customer level, KYC and KYB apply that framework through:

• customer acceptance standards;
• evidence requirements;
• risk methodology;
• approval authority;
• exception rules;
• quality assurance;
• control testing;
• change governance.

The architecture defines the control environment; the customer record shows how it was applied to one relationship.

AML program structure establishes the wider risk-based framework in which customer due diligence operates.

The AML program owns areas such as:

• enterprise risk assessment;
• policies and procedures;
• governance;
• training;
• independent testing;
• regulatory responsibilities;
• program-wide remediation.

KYC and KYB translate those program requirements into customer-level evidence, risk classifications, decisions, and lifecycle controls.

Sanctions screening owns matching logic, alert generation, false-positive resolution, list management, and screening evidence for customers, beneficial owners, representatives, counterparties, and payment data.

Resolved screening outcomes then enter KYC and KYB as inputs into:

• customer acceptance;
• enhanced due diligence;
• restrictions;
• escalation;
• ongoing review;
• relationship exit.

Screening determines the disposition of the match. The KYC/KYB decision determines what that disposition means for the customer relationship.

Transaction monitoring evaluates how an active relationship actually operates.

Its starting context comes from KYC and KYB:

• customer and entity identity;
• ownership and connected persons;
• risk classification;
• expected activity;
• approved products;
• restrictions;
• relevant jurisdictions and counterparties.

Observed activity then returns evidence that may confirm or challenge that profile.

Material differences can trigger:

• customer-profile updates;
• risk reassessment;
• enhanced due diligence;
• restrictions;
• investigation;
• remediation;
• relationship exit.

The exchange is continuous: customer context shapes monitoring, and monitoring outcomes reopen the customer decision when the facts change.

When a customer issue requires investigation, evidence review, escalation, disposition, or closure, it moves into compliance case management.

Typical entry points include:

• conflicting identity evidence;
• unresolved beneficial ownership;
• suspected impersonation;
• sanctions or PEP matches;
• adverse information;
• source-of-funds concerns;
• unusual authority arrangements;
• material monitoring findings;
• policy exceptions;
• failed remediation.

The case returns a documented disposition. That result updates the customer’s risk, decision, restriction, or review requirement instead of remaining isolated in an investigation queue.

Regulatory operations turns customer-control evidence into examination support, formal reporting, regulatory commitments, and managed remediation.

KYC and KYB contribute:

• reproducible customer decisions;
• source and evidence histories;
• approval records;
• quality findings;
• review and remediation data;
• responsibility allocation;
• population-level control metrics.

At this boundary, individual customer records become evidence of how the control operates across the institution. Regulatory operations owns the production, tracking, and response process around that evidence.

Bank–fintech compliance responsibility explains how regulated and operational duties are allocated between banks, fintechs, program managers, vendors, and other partners.

This relationship becomes material when one participant:

• controls the customer interface;
• collects evidence;
• performs verification;
• reviews exceptions;
• applies restrictions;
• monitors activity;
• retains the customer record;
• communicates with the customer;
• holds final decision authority.

KYC and KYB require a clear allocation for every material task while preserving one accountable owner for the complete customer decision.

The Banking-as-a-Service operating model defines the payment, account, technology, and sponsor-bank structure around many distributed KYC and KYB processes.

That structure determines:

• which institution holds the account;
• who contracts with the customer;
• which party operates onboarding;
• where customer data is stored;
• who controls product access;
• how restrictions reach payment systems;
• which participant performs monitoring;
• which institution responds to regulators.

KYC/KYB responsibility and payment operations therefore describe the same customer relationship from different control layers. A mismatch between them leaves approvals, restrictions, or accountability without an operational owner.

DELCOS Insights examines current regulatory changes, enforcement actions, technology developments, provider failures, and operating practices that affect KYC and KYB systems.

Permanent KYC and KYB principles remain on this page. Time-sensitive developments belong in Insights and connect back to the relevant system, control, or failure mode.