Feature engineering in banking

Plain language meaning

Feature engineering in banking converts raw customer, account, transaction, credit, fraud, AML, sanctions and operational data into controlled model inputs such as balances, velocities, histories, ratios, flags and behavioural patterns.

This topic is about bank-governed feature design. It is not about creating clever variables without explainability, stability, permitted use or point-in-time correctness.

In a real bank, this is not a loose technology choice. It affects customer outcomes, operational queues, payment execution, risk decisions, regulatory evidence, audit replay, privacy obligations and production resilience. AI should improve decision support and operating quality, but it must remain inside clear banking ownership and control boundaries.

Where it sits in the banking AI journey

This card belongs to AI Data and Model Operations. The working flow is Approved data, Feature definition, Calculation logic, Validation and lineage, and Reusable feature.

Read the flow as a bank operating model. Every stage needs a business owner, a source system, a data definition, a timing rule, an exception path, a fallback option, a monitoring requirement and retained evidence. That is the difference between a useful AI pattern and an uncontrolled technology shortcut.

Banking data and evidence

The important data points are balance trend, payment velocity, account age, utilisation ratio, delinquency count, beneficiary change, alert history, and feature timestamp. These items matter because they can alter risk scoring, payment treatment, customer communication, operational priority, reconciliation status, compliance review, model monitoring and management reporting.

The evidence pack should include feature catalogue, calculation code, test result, feature snapshot, lineage record, monitoring report, and approval note. A strong bank can replay the journey from source data to transformed input, model or rule output, human action, system outcome and monitoring result. A weak bank only knows that a process ran.

Controls that make AI adoption safe

The core controls are feature owner, definition version, point-in-time rule, calculation test, stability monitoring, bias review, and reuse approval. These controls stop AI from drifting away from banking purpose, approved policy, data governance, model-risk expectations, operational resilience, customer fairness and auditability.

The practical design should define what AI may recommend, what it must never decide alone, which deterministic rule remains authoritative, who owns overrides, how degraded service is handled and what evidence is retained. Without that, the bank may gain speed but lose explainability and control.

Data, architecture and resilience lens

AI in banking depends on the quality of the surrounding architecture. The model can only be as reliable as the data contracts, event meanings, feature definitions, API controls, batch controls, reconciliation rules, monitoring signals and fallback processes that feed and govern it.

A bank-grade design therefore connects channels, source systems, payment hubs, risk systems, data platforms, feature stores, model serving, policy engines, case tools, audit logs and reporting layers. It also defines degraded operation, recovery evidence and post-incident learning before production use.

Regulatory and governance lens

Federal Reserve SR 26-2, dated 17 April 2026, gives revised model-risk guidance for traditional models and non-generative AI models used by banking organisations, including development, validation, monitoring, change control and governance.

NIST AI RMF 1.0 uses Govern, Map, Measure and Manage functions for AI risk management, and NIST AI 600-1 adds generative-AI risk actions for source grounding, content provenance, data protection, security and human oversight.

BCBS 239 remains current for effective risk data aggregation and risk reporting, and the Basel Committee's January 2026 newsletter reiterates the importance of accurate, comprehensive and timely data capabilities in banks.

FFIEC Architecture, Infrastructure and Operations guidance expects financial-institution technology environments to be governed, resilient, secure, monitored, documented and aligned to business risk.

CPMI's February 2026 updated harmonised ISO 20022 data requirements show why consistent structured data matters for interoperable cross-border payment processing and monitoring.

CPMI-IOSCO Principles for Financial Market Infrastructures explain governance, comprehensive risk management, liquidity risk, settlement finality and operational reliability for payment, clearing and settlement systems.

OFAC's Framework for Compliance Commitments describes sanctions compliance programme components including management commitment, risk assessment, internal controls, testing and auditing, and training.

FFIEC BSA/AML examination guidance expects suspicious activity monitoring systems to be risk-based, explainable by management, periodically reviewed and independently validated where appropriate.

Diagram walkthrough

Read the diagram from left to right as Approved data, Feature definition, Calculation logic, Validation and lineage, and Reusable feature. It is a control map, not decoration. It shows how banking data, AI support, policy control, human accountability and audit evidence should connect.

Use it as a 30-minute study method. For each box, ask which system creates the data, which rule or model acts on it, what can go wrong, who can override it, how the fallback works, what customer or regulatory impact exists and what evidence proves the final state.

Most important mistake to avoid

The common failure is treating feature engineering as technical creativity while the bank needs controlled definitions that remain explainable, reproducible and fair over time.

The correction is disciplined scope. Keep the topic anchored to banking purpose, prove the data path, make ownership visible, test failure behaviour, record the evidence and make the final outcome explainable without depending on memory or assumptions.

A feature that must exist before the decision

A fraud team proposes "number of card attempts in the previous ten minutes." At a 10:15 authorization, the feature window should use eligible events observed by the feature service no later than the decision cut-off. An investigation label created the following day is not an input to that authorization. Neither is a late-arriving transaction that had not reached the bank's system in time. If training uses the complete historical event stream while production sees only what has arrived, apparent validation performance will overstate real use.

Write the feature contract before selecting a model. Define the entity key, time zone, window start and end, included transaction states, treatment of reversals, deduplication key and missing-history value. A card with no previous activity is not automatically the same as a card whose history feed failed. One may have a legitimate zero count; the other needs a missingness flag and perhaps a fallback. Document the source's lawful and approved purpose, especially when data from other products or external parties is involved.

A second example is a monthly debt-burden feature for lending. Its numerator might be verified monthly obligations and its denominator verified income over a stated period. A balance, a scheduled instalment and an overdue amount are different things. The feature owner must choose the definitions and test edge cases: variable income, joint accounts, disputed entries and a recently closed facility. A ratio may be mathematically valid but misleading if one input is stale. Feature engineering is not a clever formula layered over undefined banking data.

For a repeatable test, take one decision ID and reconstruct every feature value from dated sources and transformation code. Compare the training calculation with the serving calculation on the same snapshot; differences require investigation even if the model output looks plausible. Monitor missingness, distributions and lag by product and channel after deployment. The NIST AI RMF Measure playbook discusses data provenance, representativeness and monitoring as risk-management considerations; it is a voluntary framework, not a bank-specific regulatory mandate. It helps frame the evidence a feature owner should keep.

The feature is a decision-time contract

A feature is a measured property supplied to a model, such as recent transfer count, account age, balance volatility or a flag that a beneficiary is new. In banking, a useful feature definition must specify the customer or account entity, source events, aggregation window, reference data, decision cutoff, missing-value behavior and allowed use. A column name such as tx_count_7d is not enough. Two teams can calculate materially different values under that name while both queries run successfully.

Begin with the decision and label. A payment fraud model scores an instruction before release; its features can use information available at that moment, not a chargeback reported weeks later. A credit application model uses evidence available when the application is assessed, not repayment performance on the proposed loan. An AML alert-ranking model can use alert facts, but a final case disposition created after investigation is an outcome, not an input. Feature design is therefore inseparable from the decision timeline.

Specify the granularity. A feature may describe a customer, card, account, beneficiary, device, merchant or relationship between two entities. A customer with three accounts can have one customer-level payment count and separate account-level counts. Joining them without a stable entity model can multiply rows or mix behavior. Store entity type and key scope in the feature definition. Where entity resolution is probabilistic, preserve the match status and consider its uncertainty.

Time windows and leakage

For a rolling window, state whether the interval is open or closed at each boundary and which event time is used. "Prior seven days" for a payment at 12:00 could mean the previous 168 hours of initiated instructions, settled payments or posted ledger entries. Exclude the current instruction unless the definition explicitly includes it. Exclude later events and statuses that were unknown at scoring time. Test decisions near midnight, daylight-saving changes and source delays.

Training data often suffers from look-ahead leakage. A historical table built today may contain corrected customer relationships, final fraud outcomes and current product categories. If joined to past decisions without as-of logic, the model learns future information. Build point-in-time features from source snapshots or versioned events that reflect what was available at each decision. Compare a sample of historical rows with preserved original request records. A perfect offline metric should invite a timing investigation.

Observation windows and outcome windows are different. A credit feature might summarize six months of cash flow before application, while the label observes default over the following year. A fraud model might aggregate the prior hour but evaluate confirmed fraud over a later chargeback window. Document both, and leave enough maturity time for labels. Avoid training near the data extract boundary when outcomes are incomplete.

Delayed arrival complicates replay. An offline build may see a transaction whose event time precedes the decision but whose bank ingestion time follows it. The online model could not have used it. An accurate backtest should respect both event and availability time. Store the source watermark or recorded timestamp and define whether the model uses event-time or processing-time semantics. A later corrected analytic view can be useful, but it should not be passed off as a faithful historical serving view.

Counting transactions

Payment velocity is a common fraud feature, yet its definition has many choices. Count unique business instructions, not technical retries, unless retry behavior itself is the intended feature. Decide whether failed, reversed, held and settled payments are eligible. Use the same currency and amount rules across channels. A bank might track number of new beneficiaries in a day, value transferred to them and time since first beneficiary addition. Each statistic has different failure and abuse modes.

A transaction amount relative to a customer's usual amount can reduce scale differences, but a new customer has little history. A median over recent legitimate transactions may be robust to outliers; a simple average can be shifted by a few large transfers. Define a minimum history requirement and a separate missing or low-history state. Do not silently divide by zero or assign a ratio of zero to an unknown baseline. Adversaries may deliberately build a benign history, so monitor the feature's behavior under changing patterns.

Cross-currency amounts require an exchange-rate reference and timestamp. A nominal amount converted at today's rate can differ from the rate available at authorization. If a payment is denominated in a minor unit, a unit conversion error can make features off by a factor of 100. Validate currency codes, decimal conventions and unusual values. An amount feature should keep its source unit and transformation version for replay.

Velocity counters should be resilient to stream replay and outages. If a consumer processes the same event twice, the count must not double. If a source partition lags, the feature should carry its freshness status. A low count caused by an empty cache is not evidence of low risk. Compare online counters to independent sampled replay and reconcile expected event volumes.

Credit features

Cash-flow features can summarize income regularity, expense commitments, overdraft frequency or balance volatility. Their definitions need banking context. A transfer from the customer's own savings account is not new income. A reversal is not a second salary payment. A joint account's inflows may not all belong to the applicant. Categorization can use ML, but uncertain classifications should be visible and validated for the credit use. Affordability policies may require separate deterministic calculations rather than treating the model feature as the legal decision.

Credit bureau attributes have observation and receipt dates, match status and possible disputes. A missing bureau match is not a zero delinquency history. A feature based on delinquency should specify the facility population, time horizon, cure handling and whether disputed records are included under applicable rules. The model team should examine segment and cohort distributions and test how corrections change decisions.

Account age can mean time since first relationship, current account opening or current product conversion. A bank merger can reset one of those dates. A stable model feature requires an agreed business definition and versioned mapping across migrations. Otherwise an apparent decline in customer tenure can shift scores for an entire acquired portfolio.

Avoid proxy harms. Features such as location, device, employment or payment pattern may correlate with protected or vulnerable groups. Their presence or absence should be justified by predictive value, permitted use and fair-outcome testing. Removing an explicit protected attribute does not guarantee that other variables cannot act as proxies. Evaluate performance and decisions across relevant segments with appropriate privacy and legal review.

AML and network features

Network features may count counterparties, circular flows, shared devices or hops to a known risky entity. The graph should distinguish payment edges from inferred ownership or identity links. A weak entity match can produce a high-risk neighborhood by accident. Specify edge type, confidence, direction, time window and whether an investigation outcome was known at alert time. A graph feature should not convert suspicion into a confirmed label.

Network calculations can be expensive. A nightly graph may be appropriate for batch alert prioritization, while a real-time payment decision needs bounded features available within its latency budget. If a graph snapshot is stale, its timestamp should travel with the feature. A model that depends on a rapidly changing network may require an approved fallback when the graph pipeline lags.

An alert volume feature may reflect rules or policies that changed over time. If the bank tightened monitoring, the count can rise without a change in underlying behavior. Version the rule set and consider the effect when using alert history as a model input. Otherwise the model may learn operational policy shifts rather than customer risk.

Text and document features

Unstructured narratives, correspondence and case notes can produce embeddings, classifications or extracted entities. Source access and purpose matter: a model should not ingest confidential narratives merely because they are technically available. Remove or protect personal data where feasible, and document the language, extraction model, version and quality. OCR errors can change a monetary amount or name while leaving a plausible text string.

An LLM-derived feature such as "policy exception present" should retain a source document reference, extraction confidence or review state, and a clear handling path for unsupported outputs. A generated summary is not the original evidence. Training on later case notes can leak the investigation outcome into an earlier alert model. Separate notes by creation time and role.

Embeddings change when the encoder or preprocessing changes. A vector computed under one version may be incompatible with a serving model trained on another. Record encoder, tokenizer, normalization and index versions. Evaluate retrieval and decision effects before bulk recomputation. A silent re-embedding can shift nearest neighbors even though a feature schema still says "vector".

Missingness and defaults

Missingness can be predictive but also reflect a broken process. Distinguish no activity, no data source, delayed feed, failed identity match, withheld optional data and invalid value. Train and validate the model under each state expected in production. A median imputation from training data may make mathematical sense for a noncritical variable, but it must not mask a mandatory stale feed. Record the imputation value and version.

For a new customer, history-based features are naturally unavailable. A model trained mostly on established customers may need a separate segment, different model or policy referral. Test performance and customer outcomes for thin-file populations. Do not report aggregate model quality as if it covers customers on whom most features are missing.

A feature store should return value plus status and observation time for critical inputs. The policy layer can then distinguish a valid zero from an invalid response. If a model cannot safely score, it should reject or abstain according to the approved design. Do not encode failure as a special numeric value within a range the model could otherwise produce.

Training and serving parity

Implement a feature definition once where practical, or use independent tests to prove that batch and online paths agree. Offline tables often calculate daily aggregates after all events arrive; online counters operate on partial streams. Compare them on decisions with matched cutoffs and availability time. Investigate differences by source, customer type and window boundary. A small average difference can hide severe errors in rare high-risk cases.

Version features as semantic contracts, not just code hashes. Changing eligible payment statuses or customer linkage changes meaning even if the output type is still an integer. A model trained on one version should not consume another without evaluation. Keep a registry of source lineage, transformations, owner, tests, valid ranges, freshness limits and approved models. Deprecate old versions through a planned migration rather than reusing the same name.

Feature selection should consider stability and operational cost alongside predictive lift. A source available only from a fragile vendor can improve an offline score yet damage live decisions under outages. A highly predictive feature based on an after-the-fact operational code is leakage. A complex graph feature may be too slow for an instant payment. Measure latency, availability, bias and explainability under the intended workflow.

Validation and monitoring

Validate distributions by time, product, channel and customer cohort. Look at missingness, zero rates, extreme values, cardinality and relationships between features. Compare current values with training and recent stable periods, but diagnose genuine behavior shifts before changing thresholds. Monitor whether feature anomalies alter scores and final actions. A drift chart alone does not reveal customer harm.

Test adversarial and operational cases: transaction bursts, repeated retries, amounts near a threshold, account migrations, multiple currencies, invalid dates, delayed events and source schema changes. A fraud feature should not be easily manipulated by splitting payments or rotating a device identifier. Where adversarial behavior is possible, consider independent signals and monitor adaptation.

For a credit model, test feature calculation on approved, declined and referred applications, including corrected bureau records. For an AML model, test a relationship correction and a rule-version change. For a document model, test obsolete text, ambiguous tables and unsupported extraction. Have domain owners hand-check a sample and reconcile values to source records. Statistical unit tests that only mirror the transformation are insufficient.

Incident example

A bank updates its payment hub so that an accepted transfer emits two status events instead of one. The feature job counts events rather than unique instructions. Recent-payment velocity doubles for a subset of customers and fraud referrals increase. The serving endpoint and model are healthy. Investigation compares event counts to distinct business IDs, locates the deployment boundary and identifies decisions that used inflated features.

The bank follows its approved degraded policy while correcting the feature, then recomputes affected scores as an analytic aid. It reviews held payments and customer communications. Retraining the model on duplicated events would normalize the defect instead of fixing it. The permanent repair uses the business instruction ID, status eligibility and replay tests; monitoring alerts on the divergence between event and instruction counts.

Feature review exercise

Write a full contract for "outgoing payment value to newly added beneficiaries in the prior 24 hours." Specify who the payer is, how beneficiaries are identified, when "newly added" begins, which payment statuses count, how reversals and retries are treated, whether currency conversion is applied, and the exact cutoff. State what the service returns if beneficiary reference data is stale. Calculate the value for six hand-selected instructions with timestamps and statuses. Then replay the same six through both training and serving pipelines.

The exercise should produce a definition, test data, expected values, lineage, freshness rule, missingness behavior, model-use approval and evidence for a past decision. That is a bank-grade feature. Its value is not merely that it predicts an outcome; it is that the bank can calculate it consistently, explain it at decision time and respond when its underlying data fails.

Interaction features and causal caution

An interaction feature combines inputs, such as payment amount divided by typical balance or number of new beneficiaries multiplied by account age. Interactions can expose a pattern that a simple linear model would miss, but they can also magnify measurement error. A missing or near-zero denominator can create extreme values. Define clipping, floors and null states explicitly, then test them against real examples. A high ratio for a thin-history customer may indicate uncertainty rather than misconduct.

Correlations can reflect bank policy. A customer whose previous payments were repeatedly held may have fewer settled transactions. A feature based only on settled volume then partly encodes the bank's earlier fraud policy. A credit feature based on prior accepted offers similarly reflects selection by earlier underwriting. Analyze whether the feature measures customer behavior, operational treatment or both. A model can learn and reinforce an old decision pattern even when protected attributes are excluded.

Some features can be changed by the subject. A fraudster may spread transfers across accounts, wait just beyond a 24-hour window or rotate devices. Test how candidate features behave under plausible evasions and avoid a single brittle rule. Multiple windows and independent evidence can help, but they add operational complexity. Monitor changes in adversary tactics and feature distributions after deployment.

Aggregation and denominator choices

A rate needs a meaningful denominator. Fraud cases per transaction, per active customer and per value transferred answer different questions. A customer with one payment and one dispute has a 100 percent observed rate but little statistical evidence. Specify minimum exposure, smoothing or a separate low-sample category. If a denominator can be zero, handle it as a state rather than silently assigning a rate that looks precise.

For lending, debt-to-income measures depend on validated income and debt definitions. Net versus gross income, irregular earnings, joint obligations and recent employment changes can alter the value. The AI feature should not replace the bank's required affordability calculation without an approved policy and evidence. Where a model uses a derived ratio, retain source components and calculation version so a disputed decision can be checked.

For AML, proportion of transfers to a particular counterparty group depends on how that group is classified and on the eligible transfer population. A sudden rise can come from a reference-table update, a real behavior change or a missing domestic feed. Keep numerator, denominator and reference version visible in diagnostics. An opaque ratio conceals the cause.

Categorical encoding

Product, channel and merchant categories can change as the bank adds services. An encoder trained on existing categories needs a defined unknown-category path in production. Mapping every new product into a generic old category may distort risk. One-hot encodings can be sparse; learned embeddings can generalize but are harder to explain and may change with retraining. Evaluate the representation under expected new and rare categories, and keep the business mapping version separate from the statistical encoding version.

High-cardinality identifiers such as merchant or beneficiary ID can let a model memorize historical outcomes. That may improve short-term performance but fail for new entities and raise privacy or fairness concerns. Target encoding must be computed without leaking the validation or future labels into the encoded value. Use time-aware, out-of-fold construction where appropriate and independently test new-entity behavior. Document whether entity IDs are stable across source migrations.

Text-derived categories can be especially fragile. A merchant name or payment reference may contain spelling variation, language differences and sensitive personal information. Normalization and classification should be versioned, with an unknown or low-confidence state. Review samples of errors by language and customer group. A model that performs well on common English descriptions may fail on a significant minority of transactions.

Privacy and minimization

Feature stores can become wide copies of sensitive banking data. Before adding a feature, ask whether the same decision value can be obtained with less raw information, shorter retention or a coarser derived measure. Restrict access by purpose and role; separate training, serving and investigation permissions. A hashed identifier can still be linkable and personal data under relevant rules. Document lawful basis and retention with the bank's privacy and legal teams.

Do not insert raw free text into shared model telemetry simply to make debugging easy. Log a protected source reference, extraction status and approved derived value where that suffices. For a disputed case, an authorized reviewer can retrieve the original evidence. Monitor feature access and export, especially when external vendors are involved. A predictive feature is not automatically an appropriate feature to use.

Feature lineage should include sensitive transformations. If a customer requests correction, a source update can propagate to cached features, training datasets and model evaluation. Maintain the ability to identify affected artifacts and follow applicable retention and correction rules. A model's parameters cannot always be edited one record at a time; governance should describe how corrections and retraining are handled.

Deployment migration

Suppose a bank changes its customer key service. The new mapping merges some accounts that were previously separate. Run old and new feature calculations in parallel on a controlled decision sample, including joint accounts, closed accounts and recently acquired customers. Compare values and resulting scores, then investigate outliers. Approve the model's continued use under the new mapping only after evaluating performance and customer effects.

Deploy a semantic feature version, not an in-place overwrite. Record which requests used each version. If the new service fails, an old mapping may not be safe to restore after downstream IDs change; design rollback with compatible source versions. A shadow model can compare scores without affecting customers, but shadow outputs are not final decisions. Reconcile the actual policy actions separately.

Monitor the transition by source cohort. An overall average can mask a severe change for acquired accounts or new customers. Keep an affected-population query ready in case a mapping defect is found later. A source migration is a model-risk event when it changes the values on which decisions depend.

Evaluation beyond lift

Candidate feature selection should report out-of-time model performance, calibration, error by relevant segment, stability across economic periods and operational availability. A feature that adds a small gain but fails frequently during peak payment volume may reduce real-world performance. Compare the action policy with and without the feature, not just an abstract score metric. Measure holds, losses, referrals, workload and customer outcomes at plausible thresholds.

Use ablation carefully. Removing a correlated feature may appear to have little effect because another feature substitutes for it. A feature that is essential for explaining a particular rare scenario can be missed by an average metric. Conversely, an apparent large gain can result from leakage or duplicated customers across evaluation sets. Inspect source timing and create held-out stress cases.

Document tradeoffs and limitations in the model inventory. Validation should challenge whether the feature is stable, lawful, available at decision time and supported by a fallback. The bank should know which feature failures cause a model to abstain, which can be safely imputed and which require policy review. Those conditions are part of the approved model use.

Reproducibility exercise

Pick one fraud hold and one release from the same hour. Reconstruct every feature value from source events and reference snapshots as available at each decision time. Include source watermark, entity mapping, transformation version and missingness states. Compare the stored online vector to a point-in-time offline rebuild. Explain each difference before accepting the replay. Then alter one source event in a controlled test and predict how the feature and policy action should change.

For a credit application, repeat with a corrected bureau attribute. Preserve the original decision record, calculate a corrected scenario and distinguish a changed model score from a changed final outcome. A reviewer should be able to trace from source correction to feature, score, rule and customer action. If this chain fails, the feature's predictive utility is not enough for production use.

Operational sign-off

Before approving a new feature, ask the source owner to confirm meaning and timing, the business owner to confirm relevance and acceptable failure behavior, the model developer to show out-of-time evidence, and an independent reviewer to challenge leakage and segment effects. The serving team should demonstrate that a missing or stale value carries a visible status. Operations should know which alert identifies a broken feed and how to list decisions that consumed it. These are separate responsibilities; a single data-science notebook cannot prove them all.

Keep a small reference suite of hand-calculated decisions through future releases. Include ordinary, rare, late, missing and corrected records. Run the suite after a source, mapping or feature-store change. Review the resulting model and policy actions as well as raw feature equality. A feature can have the expected numeric value under a changed source meaning and still be wrong for the bank's decision. The contract therefore needs business examples alongside code and metrics.

Finally, schedule revalidation when behavior or operating conditions change. A feature that represented suspicious novelty at launch may become common after a new payment product is introduced. A credit cash-flow measure can behave differently during economic stress. Monitor its meaning, availability and action effect over time. When the evidence no longer supports its use, revise or retire it through controlled model change rather than preserving it for historical predictive lift.

Hand-check a velocity feature

Define distinct outbound payment instructions to a newly added beneficiary in the prior 24 hours. At 09:00 the customer sends one transfer; a network retry produces a second message with the same business instruction ID. At 10:00 a second genuine transfer occurs. At 11:00 the beneficiary directory changes the payee's status. The feature at each decision must use the identity and reference state available then, count the retry once and exclude the current instruction.

Write expected values by hand before implementing batch and online calculations. Include a missing-directory response and a late prior event. Compare the stored live vector with a point-in-time rebuild respecting availability time. If the bank later corrects the beneficiary mapping, keep the original vector and a separate corrected scenario. The feature contract should name event statuses, window boundaries, key scope, null behavior and freshness limit so a reviewer can reproduce the score. Include a replayed source event and a currency conversion at a dated rate. If the online counter and offline build disagree, classify whether the difference comes from late arrival, reference version or a code defect before changing the model. Preserve both calculations and the actual payment action.