Customer features and behavioural signals

How to study this topic

Customer features and behavioural signals help a bank understand relationship quality, financial stress, engagement, vulnerability, suitability, risk movement, and service needs without reducing the customer to one crude score. Study this chapter as a banking control topic first and a data science topic second. The model is not the beginning of the story. The beginning is the bank's duty to know what happened, where the data came from, whether it is complete, whether it is reconciled, whether it is allowed to be used, and whether the result can be explained later.

The banking meaning

customer features and behavioural signals is important because banking data carries legal, financial, customer and regulatory meaning. A balance is not just a number. A balance may be available, booked, ledger, cleared, unsettled, blocked, earmarked, overdrawn or adjusted. A customer status is not just a label. It may affect onboarding, credit treatment, servicing, conduct obligations, complaints, vulnerable customer handling and regulatory reporting.

Sources and boundaries

Typical sources include customer tenure, relationship depth, income pattern, balance stability, credit usage, savings behaviour, digital engagement, complaint history, service interactions, risk rating movement, life-event indicators, and consent and preference data. These sources do not have equal authority. A digital channel may show customer intent, but a book-of-record platform may show final outcome. A CRM note may show relationship context, but it may not be structured enough for automated model use. A risk system may hold a rating, but the rating may have a valid-from date, expiry date, override reason or review cycle.

Why AI depends on this discipline

The practical AI use cases include next best action, credit affordability support, financial difficulty early warning, customer service prioritisation, relationship management, complaint triage, retention analytics, and product suitability checks. These can help a bank act faster and with more consistency, but only if the model input has banking quality. A model trained on weak data can still produce a neat score, rank, category or recommendation. The output may look professional while the underlying evidence is damaged.

AI does not remove the need for banking controls. It makes those controls more important because one bad input can influence many downstream decisions at speed. The safest banks treat model input preparation as part of governance, not as background plumbing.

Validation controls

Validation asks whether the data is acceptable for its intended use. For this topic, useful controls include consent review, privacy classification, purpose limitation, vulnerability controls, and fairness review. These controls should run before data becomes a model feature, dashboard metric, risk indicator or operational priority. The controls must check both technical shape and banking meaning.

Validation should produce actionable exceptions. It should say what failed, why it matters, which downstream consumers are affected, whether the model must stop, whether degraded use is allowed, and who owns correction. A generic red status is not enough for production banking.

Operational design

Operational resilience also means fallback. If the feature feed is unavailable, should the bank stop the model, use the last good value, route to manual review, switch to a rule-based control, or degrade the service? The answer must be designed before failure.

Governance and audit

BCBS 239, model-risk guidance and AI-risk frameworks all point in the same practical direction: banks need controlled data, clear limitations, documented governance and monitoring. The details differ by jurisdiction and model type, but the core discipline is stable.

Common mistakes

The final mistake is rushing feature reuse. Centralised features are powerful, but reuse without purpose control can create hidden risk. The same feature may be safe for portfolio monitoring and unsafe for direct customer decisioning. A bank must know the difference.

Bank-ready checklist

If these questions are answered well, AI adoption becomes much safer. The bank is not merely feeding data into a model. It is turning banking evidence into controlled decision support.

Source anchors for further study

BCBS 239 supports the banking discipline of accurate, complete, timely and adaptable risk data aggregation and reporting.

Model-risk guidance such as the Federal Reserve supervisory guidance emphasises input quality, data constraints, limitations, validation, monitoring, documentation and governance.

NIST AI RMF is useful as a general AI risk framing for governance, mapping, measuring and managing AI risk, but banking still needs bank-specific controls around customers, products, books of record, risk and regulatory evidence.

Practical banking note on business meaning

For customer features and behavioural signals, the business meaning point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

The practical discipline is to keep four layers separate: observed banking fact, derived data signal, model interpretation and business action. Observed facts come from systems such as customer tenure, relationship depth, income pattern, balance stability, and credit usage. Derived signals reshape those facts into features or indicators. Model interpretation produces a score, classification, ranking or recommendation. Business action decides what the bank will actually do. When these layers are blurred, nobody can explain the result properly.

Practical banking note on lineage

For customer features and behavioural signals, the lineage point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Practical banking note on customer impact

For customer features and behavioural signals, the customer impact point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Practical banking note on risk control

For customer features and behavioural signals, the risk control point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Practical banking note on model limitation

For customer features and behavioural signals, the model limitation point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Practical banking note on operational fallback

For customer features and behavioural signals, the operational fallback point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Practical banking note on audit evidence

For customer features and behavioural signals, the audit evidence point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Practical banking note on privacy and permitted use

For customer features and behavioural signals, the privacy and permitted use point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Practical banking note on feature reuse

For customer features and behavioural signals, the feature reuse point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Practical banking note on monitoring

For customer features and behavioural signals, the monitoring point matters because banking AI does not live in isolation. It sits beside customer journeys, product ledgers, risk controls, finance numbers, operations queues, compliance obligations, audit evidence and management decisions. A weak data point can move quietly through all of these areas unless the bank designs controls that stop, flag or limit it.

Define the customer and the behavior

A customer feature may summarize account tenure, product use, repayment pattern, channel activity or service interactions. It must begin with a defined entity and purpose. A retail person, a joint account, a sole trader and a corporate legal entity do not have identical relationships to accounts or transactions. A feature called customer payment frequency is ambiguous until the bank says which accounts, authorized users, products, channels, states and time window count. A person using a business account may create legitimate activity that should not be attributed to their personal credit decision. The identity and relationship map needs effective dates and source evidence.

Behavior is observed through bank systems, not directly through a customer's intent. A login can be a successful authenticated session, an attempted login, a service retry or a bot-blocked request. A payment submission can be an intended order, a duplicate retry, a held instruction or a released transfer. A complaint may reflect a product problem or a customer seeking clarification. Turning these events into a single engaged or risky score without definitions can punish customers for the bank's own errors. The feature contract should describe the event boundary and the business interpretation that has been validated for the particular model.

Build a behavioral feature without future knowledge

Suppose a bank wants a thirty-day count of new beneficiaries for pre-release fraud review. At the scoring time, it can use accepted prior instructions and beneficiary identity information available to the hub. It cannot use a later investigation disposition or corrected beneficiary mapping that arrived after the decision. Define whether an attempted but held payment counts as a beneficiary introduction and how a transport retry is deduplicated. A customer might save a beneficiary in a channel before sending anything; that saved template is a different event from a payment. A feature built from saved templates may be useful, but it should have its own name and validation.

Store source event IDs, customer and account relationship version, beneficiary identity rule, window start, cutoff, calculation version and missingness state. The current payment should not count as its own prior behavior. Test two same-amount orders, a repaired account, a customer ID merge, a transaction arriving late and a new channel whose template events are unavailable. Compare online and offline values at sampled decision times. If the feature is stale because a channel stopped publishing events, the model service must use its approved fallback or refer cases. It should not present a zero count as evidence of low risk.

Customer tenure is not one date

Account opening, first funded transaction, first product relationship and first digital login can differ by years. A credit model may need time since the relevant credit relationship began; a service model may need time since a particular channel was adopted. A migration can create a new technical account ID for an old relationship. Define the tenure event, population and migration mapping. If a new platform loses the predecessor link, the feature may suddenly label long-standing customers as new. That change can alter approval, fraud challenge or customer treatment without any genuine change in the customer.

Test a migrated account, a dormant account reactivated, a joint account holder added later and a corporate group restructure. Use the relationship state known at each decision time. Do not overwrite historical tenure with today's merged master state. A validator can compare feature distribution before and after migration and trace a sample to source contracts or account records. The business owner decides whether a technical migration should be neutral to the model action and documents any exception. This is a feature-governance question, not simply a data cleanup task.

Segment and fairness review

Behavioral data reflects access and opportunity. Some customers use a branch or assisted channel rather than a mobile app. A device-change feature may be common for customers replacing a phone. A sparse digital history can reflect a new-to-bank relationship, disability, age, connectivity or product design, not misconduct. A model that equates absence of app activity with risk needs evidence that the feature is relevant to the approved decision and does not cause unacceptable harm. Review performance and actions across relevant groups where lawful and feasible, investigate differences and document the outcome.

The bank should not infer sensitive attributes from behavior merely because a model can. A location pattern, contact frequency or complaint text can reveal personal circumstances. Apply purpose limitation, minimum necessary data, retention and access controls. For a customer-service triage model, use the facts needed to route a case; for a credit model, do not import unrelated service sentiment without a strong lawful and validated reason. An explanation method can show that a feature influenced a score but cannot establish that the feature was fair or appropriate. The model-use decision remains with accountable owners.

A worked missed-payment feature

Define missed scheduled instalments in the prior twelve completed months for a loan. The source schedule identifies due dates and expected amounts; the ledger records payments, reversals and adjustments. The contract states grace periods, partial payments, holidays, restructures and product-specific rules. The value is not simply the number of months with no posted credit, because a payment could be made through another channel or legitimately deferred. A customer with no prior loan history has missing history, not zero missed instalments under every interpretation.

At application time, store the schedule and ledger versions available then. A reversal posted after the decision can affect current risk analysis but should not be inserted into an earlier replay. A later hardship arrangement may change future obligations, not erase a past event without policy basis. Test a payment exactly on the grace boundary, a partial amount, a reversed posting and a migrated facility. Compare the feature with an independent operations calculation for sampled accounts. If the feature informs an adverse credit action, the bank must be able to identify the actual principal reasons under applicable law and policy, not just cite a model score.

Monitoring and interventions

Customer behavior shifts when the bank changes channels, fees, products or communication. A rise in mobile logins after a new app launch is not necessarily a change in fraud risk. Monitor source coverage and feature distributions by channel and product release, then assess model outcomes after they mature. Compare with a simpler baseline and review false holds, referrals, customer complaints and missed cases. If a source outage causes missingness, communicate the model restriction to operations. Do not retrain on a short period of selectively investigated cases just to restore an aggregate metric.

When a feature triggers an action, record the exact threshold and policy. A high new-beneficiary count might lead to a challenge, while a missed-payment feature may prompt manual credit review. Those actions have different customer impact and human oversight. A clear customer-feature design traces raw behavior to calculation, model output, policy action and later outcome without claiming to know intent from an event count. That is the basis for a defensible banking ML use.

Observation and outcome windows

A behavioral model needs separate clocks for its features and its target. For example, a fraud model can use the beneficiary introductions observed before a payment is released; its outcome may be confirmed after an investigation days later. The outcome is appropriate for subsequent validation, but it cannot be fed back into the features for the original score. A credit model may observe repayment behavior through the application date and label default over a later twelve-month horizon. The development record should identify the observation cutoff, prediction horizon and minimum maturity of the outcome. This makes it possible to distinguish a genuine predictive relationship from information that became available only because the customer already experienced the event.

Population selection matters as much as the clock. A repayment-history feature exists for borrowers with an active facility, but a first-time applicant may have no comparable bank history. A model trained only on previously approved borrowers may perform differently for referred or rejected applicants. Record which customers could enter the training sample, which were excluded, how missing history was encoded and how the model behaves in each cohort. A field that predicts default in an existing-loan portfolio should not be assumed valid for new-to-bank applicants. Test the intended decision population, not just the records that are easiest to assemble.

Identity changes and household boundaries

Customer master systems merge duplicates and split incorrectly joined profiles. A corrected identity can improve today's data while changing a historical calculation if the pipeline naively reprocesses old events using the current map. Store a versioned relationship between person, account and event, and retain the mapping seen at the decision time. For a joint account, distinguish account activity from the action of an individual holder. A bank may use an account-level behavior feature for a product decision, but attributing every payment to every holder as personal behavior requires a separate justification and test. An authorized user's card activity similarly must not be silently assigned to the primary holder in a model that claims to describe individual conduct.

Consider two customers who were accidentally assigned one profile. The erroneous combined history produces a high transfer velocity and a fraud hold. Once the bank separates them, a replay of the old decision should still show the incorrect combined input that was actually used, while the incident review uses the corrected identity to identify the affected cases. Overwriting the original feature would conceal the cause of the hold. Monitoring can detect sudden jumps in account counts per person and unusually large changes after merges. The response includes correcting the source relationship, assessing the model decisions and notifying the responsible control owner, rather than merely updating a feature table.

Testing a behavioral claim

An analyst should write down what a feature is supposed to represent before evaluating its correlation with a target. If repeated failed logins are proposed as a fraud signal, compare a true authentication failure with a password-reset flow, an automated retry and a temporary identity-provider outage. If the feature counts all four, a spike may measure a bank outage. Freeze a sample of raw events and expected feature values, including boundary times and duplicate IDs, then compare the production calculation. Evaluate the model's incremental performance against a baseline without the feature, including false challenges and referral workload. Investigate whether the signal persists after a channel change and in relevant customer groups.

The analyst must also consider intervention effects. A fraud hold prevents a transaction from completing, so the absence of a subsequent confirmed fraud loss is not proof that the original alert was false. Investigators select some cases for review, creating selective labels. Credit outreach can change repayment behavior after an early-warning score. Evaluation should record who was alerted, what action followed and which outcomes were observable. Where the bank cannot identify a counterfactual outcome, report the limitation rather than treating the observed label as an unbiased measure of model quality.

Feature service contract

A production service should return the feature value with an as-of timestamp, calculation version, source freshness and a reason for a missing value. The consuming model needs a documented maximum age and a fallback for each missingness reason. A field named last-thirty-day activity is misleading if the source was last updated five days ago; the service should expose that delay so the decision path can refer or use an approved alternative. Check access by model purpose, not only by engineering team. Record which model requested which feature version, and retain the exact response used for the score.

Before releasing a new behavioral feature, test a normal customer, a new customer, a migrated account, an outage, a duplicate event, a delayed event and a customer with a contested relationship. Compare the score and policy action in each case. The bank then monitors source coverage, missingness, model outcomes and customer complaints together. This connects the ML abstraction to an actual banking decision and gives reviewers a way to challenge the assumptions behind the feature.

Observe behavior at a defined customer boundary

Customer behavior can include product use, payment timing, balance variation and channel activity. A bank must first choose an identity and decision context. A fraud model considering a card purchase may use a customer-level cross-account transfer pattern; a credit application model may use permitted repayment history known at application time. Household or device links are not automatically reliable customer identity. Record identity-resolution version and investigate duplicate or merged records before aggregating activity.

Consider a customer who makes regular payroll deposits and weekly bill payments. A recent drop in deposit frequency may be meaningful for an affordability review, but a missing payroll feed can produce the same numeric pattern. Test source completeness, employment cycle and elapsed observation time before labeling a "behavioral change." The feature should expose insufficient history and recent source outages. It should not treat a new customer with no observed deposits as the same as a long-standing customer whose deposits stopped.

Build a time-bounded example

At an application on 1 June, calculate deposits and negative-balance days over an approved prior window. Exclude transactions that arrived or were corrected after the application cutoff if the goal is a historic decision simulation. A salary credited on 2 June cannot support the 1 June decision. Reversed credits require a defined treatment; gross inflows can overstate ability to pay if transfers between a customer's own accounts are counted as income. Trace three sample deposits to source transaction purpose and reversal status.

For a live fraud score, the recent interaction pattern may involve login time, channel, session age and new beneficiary creation. These are behavioral signals, not identity proof. A customer using a new phone while traveling can look unusual without being fraudulent. A stolen session can look familiar. Evaluate combinations with policy and verification evidence; do not let one novelty feature become an unreviewed automatic block. Report false holds by customer segment and channel as well as confirmed fraud detection.

Missingness, consent and scope

Data availability differs between mobile, branch, API and corporate file channels. A branch instruction may have no device fingerprint by design. Encode channel applicability separately from a missing expected value. If a source is down, the decision service should receive an invalidity signal and follow an approved fallback. If use of a behavioral data source is restricted by purpose or permission, access control should prevent the feature from being built for an unauthorized use; a model score is not a substitute for that decision.

Behavioral history can change when an account is migrated or a product closes. Preserve prior identifiers and event meaning under a versioned mapping. A loyalty metric such as tenure may inadvertently measure only time since a platform migration if the legacy start date was dropped. Compare tenure against source contracts and sample accounts spanning the migration. A sharp population-wide drop is a data defect candidate, not sudden customer behavior.

Evaluation and action

Compare a candidate signal with a baseline on a held-out, matured cohort. For credit, assess calibration and decision effects across approved segments, with explicit treatment of customers lacking sufficient history. For fraud, measure prevented confirmed attempts, missed settled loss, false holds and investigation load, not just ranking quality. Existing policy actions change which outcomes can be observed; account for blocked and reviewed transactions when interpreting results.

Investigate a customer whose feature changed sharply. Show raw events, excluded internal transfers, source availability, calculation window, prior value, score difference and final action. Ask whether a correction would have changed the action and whether any customer remediation is needed. Monitoring should separate true changes in customer behavior from changes in channel mix, feed coverage or feature definition. The usable signal is the one whose meaning, timing and customer effect remain clear under these checks.

A customer changed identity, not behaviour

A fictional bank uses a customer-activity feature to help decide whether an unusual transfer needs review. On Monday, a customer has two retail accounts, one opened years ago and another recently. On Tuesday, the master-data team merges a duplicate profile, linking both accounts to one customer ID. A dashboard now shows a longer history for the merged customer. That does not mean the customer's behaviour suddenly changed on Tuesday, and a Monday model score must not be reconstructed with Tuesday's relationship map.

Define the subject of each feature. Login frequency may belong to an authenticated user; transfer velocity may belong to an account or resolved legal customer; repayment behaviour may belong to a facility; relationship tenure may belong to a product contract. Putting them all under a field named customer_id invites inappropriate aggregation. A family member with authority to initiate payments is not necessarily the borrower on a loan. A corporate user may operate accounts for several legal entities. The feature contract should state entity, join rule, permissible purpose and the version of the relationship used at score time.

Build an as-of activity window for a transfer submitted at 15:00. Count eligible accepted transfers in the preceding seven days by the chosen entity, excluding the current instruction, transport retries, rejected submissions and reversals according to documented rules. Store event time and availability time. An accepted instruction from 14:45 that reaches the feature service at 15:03 was not available to this score. A later rebuild may include it in a corrected analytical view, but the decision journal should keep the actual value served at 15:00.

Now consider an absence of activity. It can mean a genuinely dormant customer, a new customer without enough history, a channel that does not publish events, an identity join failure or a feed outage. Do not encode all five as zero. A model can use separate history coverage and freshness indicators, and the policy can refer or degrade when critical evidence is unavailable. Test an account that has never transacted, a customer whose records were merged, a joint account, an API channel with delayed events and a corporate user who switches legal entities. Expected feature values should follow from the declared subject and cutoff.

From signal to customer treatment

An activity change can help a bank prioritise review, but it is not proof of suspicious intent. A seasonal business may show abrupt volume shifts. A customer may change device after replacing a phone, travel, or begin using an instant-payment product. Evaluate the feature across relevant segments and channels, with enough historical context to distinguish product adoption from abnormality. If a monitoring model repeatedly refers one group because its history is sparse, review data coverage and customer friction before moving the threshold.

Govern access to behavioral signals. A session identifier, location signal and beneficiary history have different sensitivity and retention needs. The model should receive only approved derived attributes for its decision purpose. An investigator may need the underlying event under controlled access; a general analytics report may need aggregates. Keep the link from derived value to source evidence without copying all raw personal data into a score log. When consent or another lawful basis changes, the feature service must apply the approved data-use rule, not merely continue because data remains technically reachable.

For acceptance, create a small timeline with source events, profile merge, score request and later correction. Ask two questions for every case: what should the live model have seen then, and what does the bank know now? Both answers can be valid and different. This separation lets model validation reproduce the original decision, lets operations investigate a current case and prevents a customer-master update from masquerading as a change in customer behavior.

A customer changes products, not identity

An account migration creates new account numbers for a customer whose relationship began years earlier. A behavioral model calculating tenure from the new account's opening date would report a recent customer. A transaction model might also appear to lose history. Use a dated crosswalk between old and new accounts, with validation for one-to-many links and closures. Check an ordinary migrated account, a merged customer and an ambiguous joint account. Preserve the relationship version used for historic scores; a corrected crosswalk should create a separate analytic reconstruction and affected-decision list.

For a customer with current and savings accounts, transfers between those accounts can make deposit volume and spending volume look higher without changing financial resources. Classify internal transfers and reversals under a documented rule. If the bank cannot verify that both accounts belong to the same customer at the decision cutoff, do not silently exclude or include the transfer. A feature may need an unknown state, referral or limited model use depending on its decision purpose.

Detect a genuine change

Suppose a long-standing customer receives payroll credits on the last working day of each month. The April credit arrives on 2 May because of a holiday. A calendar-month feature may show no April salary, while a rolling interval includes it. Neither calculation is automatically wrong; the contract should state the period and test a boundary month. Review source coverage and payer identity before interpreting the missing April value as financial distress. A batch feed that arrived late can mimic the same pattern and must be reported as incomplete data.

For fraud, behavior may involve a newly added payee, new device session and several quick transfers. A normal customer buying a replacement phone and paying a contractor may share these signals. A stolen session can retain a familiar device fingerprint. Examine model and policy decisions against confirmed outcomes, false holds and customer delay. A behavioral signal supports risk assessment; it is not an accusation or identity proof. An investigator needs event IDs and verification history, not only a score.

Source pathways and selection

Digital banking customers may have rich session and device history; branch and corporate file customers may have little of it. If a model trained mainly on mobile behavior is applied to branch transactions, missing signals can be mistaken for novelty. Measure feature coverage and error by channel, and use distinct eligibility or validated variants where needed. A missing expected mobile field after a feed failure differs from a field that is never collected at a branch. Preserve these states through training and serving.

Open-banking or other external transaction history can cover only customers with the applicable access and available feed. Compare approved use, consent or other lawful basis, data freshness and representativeness. A model trained on consenting customers may perform differently for those without that pathway. Do not use a propensity to share data as a hidden substitute for creditworthiness. Evaluate customer effects and offer the institution's approved alternative evidence route.

Feedback from actions

A risk intervention can change behavior. A held payment never settles on its original schedule; a credit-limit reduction can change later utilization. When retraining, record intervention and observation mechanism rather than treating all subsequent data as unmediated customer behavior. A customer-service outreach can improve an outcome and also select who is observed. Compare cohorts carefully and retain action logs.

For a review exercise, choose two customers with identical recent transaction totals but different histories: one has a stable monthly pattern with a delayed feed, the other has a genuine burst of new outbound instructions. Reconstruct source events, identity links, feature validity and final actions. The lesson is to distinguish observed behavior from the system's ability to observe it at the relevant time.

Investigate a sudden tenure drop

A dashboard shows that half of a bank's active customers became "new" overnight. The customer feature pipeline has not failed technically; it now reads a platform account-open date instead of the original relationship-open date. Select migrated, nonmigrated and joint-account samples, trace source identifiers and compare both tenure definitions. The model owner identifies which score and action cohorts used the new value. A later mapping fix restores future values, while original decisions remain in the journal for impact review.

Suppose the affected model prioritized customer outreach rather than credit declines. The bank still checks whether legitimate customers were missed or contacted incorrectly. It should not automatically claim harm from a changed score, nor dismiss the defect because no direct decline occurred. Reconcile actual outreach, complaints and service cases, and test a shadow comparison on the corrected mapping. The source owner maintains a versioned crosswalk so a future migration cannot silently reset history again.

Primary sources for further study

• Feast feature views
• NIST AI RMF Measure playbook