Real time and batch data pipeline design

Plain language meaning

Real time and batch data pipeline design explains how banks move data into AI workflows through event streams, APIs, files, warehouse jobs, reconciliation runs and curated data products without losing quality, lineage or resilience.

This topic is about bank data pipeline design for AI. It is not about choosing streaming because it sounds modern or batch because it is easier to control.

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 Source systems, Ingestion mode, Quality and reconciliation, Curated store, and AI consumption.

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 event stream, API payload, file batch, load timestamp, schema version, record count, control total, and consumer status. 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 pipeline run log, schema version, quality result, reconciliation report, consumer acknowledgement, replay report, and lineage graph. 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 schema contract, load validation, idempotency, late-event handling, batch control total, replay procedure, and data-product owner. 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 Source systems, Ingestion mode, Quality and reconciliation, Curated store, and AI consumption. 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 designing pipelines around transport mechanics while ignoring whether AI receives complete, current, reconciled and explainable banking data.

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.

Two pipelines with one definition of an eligible event

A bank may score a payment in a live authorization flow and also run an overnight fraud-analysis batch. The real-time path must make a bounded decision within the channel's deadline. It receives an event, validates schema and essential features, produces a score or explicit failure, and passes that result to a policy control. The batch path can reconcile a dated population and join later case outcomes. They may share definitions, but their availability and failure contracts differ. Calling both paths "the same model" does not make their inputs equivalent.

Suppose a payment event is emitted twice after a network retry. The live pipeline needs an idempotency key so the second event does not create a second policy action. The batch pipeline needs to count the duplicate, apply its documented deduplication rule and reconcile raw versus eligible records. If an event arrives after a window closes, the batch owner records whether it is included in a corrected run or excluded with a reason. Quietly mutating yesterday's published extract undermines replay. Event time and processing time belong in separate fields.

A practical architecture test starts with four cases: normal event, late event, duplicated event and unavailable feature source. For each, state the customer or operations impact, output status, retry rule, fallback owner and audit evidence. A live service should not turn a timeout into a benign score; a batch job should not call a partial feed complete. Monitor freshness, latency, failure rates and counts at hand-offs, not only the final model endpoint. A green endpoint may consume stale features.

The analyst should specify whether the nightly result is used for a new decision, monitoring only, or an investigator worklist. A Tuesday batch score must not retroactively replace the score that justified a Monday payment action. If a corrected event changes the outcome, record the correction and its effective time while preserving the original decision. The NIST AI RMF playbook provides a general risk-management lens for provenance and ongoing monitoring; bank-specific deadlines, retention and operational controls must be set by the institution and applicable requirements.

Choose a clock for the decision

Real-time and batch pipelines solve different timing problems. An instant-payment fraud decision needs a bounded response before the instruction proceeds. A monthly credit-risk review can assemble a controlled portfolio snapshot overnight. An AML alert service may ingest events continuously but produce ranked case queues periodically. The design begins with the business decision deadline, the source arrival pattern, the amount of data needed and the consequence of stale or incomplete output.

Real time does not mean every component has zero delay. A payment request may be scored in milliseconds using features whose underlying account history was last refreshed minutes earlier. A batch run may be highly current at a published cutoff but not serve individual requests. State the observation timestamp, computation watermark and publication time separately. A model response that is fast but based on stale features is not a fresh decision.

Map the flow from source event to final action. A payment channel sends an instruction; a hub validates it; source streams update features; a serving service returns a score; a policy engine combines the score with rules; the hub executes, holds or rejects; case and ledger systems record subsequent status. A batch credit pipeline extracts eligible applications or accounts, reconciles the population, computes features, scores a frozen snapshot and publishes reviewed actions. Each stage needs an owner and an error path.

Source capture and contracts

Source systems should publish stable business IDs, event types, timestamps, status transitions and schema versions. A payment event may be an instruction, authorization, settlement, return or technical retry. A stream consumer that counts all of them as independent transfers corrupts velocity features. A batch extract that omits canceled applications can bias a training set. Agree on eligible events with business owners before writing transformations.

Change-data capture can transmit database changes, but a database row update is not always a business event. A corrected address, payment status or account mapping may replace a value without exposing why it changed. An event log provides a lifecycle but may require snapshots to reconstruct initial state. Choose source capture according to audit and replay needs, and test deletes, corrections, late messages and schema migrations.

Publish data contracts covering expected volume, key scope, time semantics, allowed nulls, classifications, privacy level and delivery cadence. An upstream team should signal a field meaning change before it enters the feature pipeline. A syntactically compatible code can acquire a new business meaning. Compare sample decisions across old and new versions, not only schema validation results.

Streaming architecture

A streaming consumer reads events from a durable source, validates and deduplicates them, resolves identities and updates stateful aggregates. Partitioning by account or customer can preserve local order for a velocity feature, but cross-account patterns may require another aggregation step. The choice affects latency and consistency. A hot customer or merchant can create a skewed partition and delay decisions even if average throughput looks healthy.

Delivery is often at least once. Consumers must use event IDs and business instruction IDs to avoid counting a replay twice. Exactly-once claims require scrutiny at the full business boundary: a broker might commit a message once while a case API or payment action is retried independently. A model call should be idempotent as a request; a late response should not cause a second instruction execution. Maintain separate attempt and decision IDs.

Watermarks describe how far event-time processing has progressed. A late event can be incorporated into a corrected aggregate, but it cannot retroactively change an already executed payment. Preserve original feature snapshots for decisions and compute a separate corrected view for incident analysis. Monitor lag by partition and source, not only the newest message across the topic. A single stuck partition can affect a meaningful customer group.

State stores need capacity, recovery and retention plans. A 24-hour rolling count can use bounded state, while long customer history may require another store. Test recovery from a checkpoint and replay of a large backlog. If a restarted consumer starts with empty state, a model can see zero velocity for many customers while the stream looks alive. A freshness and completeness flag should prevent silent use of partial state.

Batch architecture

A batch run should freeze an input cutoff and expected population. Extract source files or tables, check completeness and control totals, transform and join data, compute features, score with a versioned model, and publish results only after gates pass. The run ID should link inputs, code, model, policy, output and approval. A rerun with corrected inputs is a new version, not an overwrite that erases the earlier published result.

Batch joins are particularly vulnerable to duplicated keys and drifting reference versions. Count rows before and after joins, measure unmatched records and reconcile totals. A credit portfolio snapshot should identify which facilities were active at cutoff, how restructures are handled and which customer relationships were effective. A successful scheduler exit code does not prove that the right population was scored.

Publication can be atomic: downstream systems see the previous approved version until the new output is complete and validated. If a partial result is deliberately released, label its coverage and restrictions. Do not mix half of yesterday's scores with half of today's without a rule. Keep a last good snapshot only within an approved age window; stale scores can be harmful if account conditions change.

Hybrid paths

Many bank decisions need both. A real-time payment score can combine a live event with batch-built customer baselines. A batch feature such as typical monthly transfer amount may be refreshed daily, while an online counter tracks transfers in the past hour. Each feature needs its own observation and publication timestamp. The model should know when an input is missing or stale, and the policy layer should have a tested fallback.

A nightly customer graph can inform real-time AML or fraud decisions, but it may miss relationships discovered during the day. A streaming update may add recent edges without recomputing global graph statistics. Validate how the mixture behaves and whether a graph snapshot's age is acceptable. Label the decision with both versions. A single "model version" does not capture its data state.

Training uses historical data constructed to mimic serving. If an offline pipeline computes features after all late events and corrections are available, it may overstate production performance. Build point-in-time snapshots respecting both event time and availability time. Compare online recorded vectors with offline reconstruction on a sampled decision set. Investigate discrepancies rather than treating them as normal implementation noise.

Latency and capacity

Allocate an end-to-end time budget. If a payment decision has 200 milliseconds, reserve time for source lookup, feature retrieval, model inference, policy evaluation, logging and network variability. A model endpoint with a 50-millisecond median can still breach the business deadline at the 99th percentile. Measure tail latency under peak traffic and partial failures. A retry can consume the remaining budget and amplify load.

Capacity planning should include burst behavior, not just daily averages. Salary dates, holidays and promotions can create sharp transaction spikes. Streaming partitions, feature stores and model servers need scaling that does not compromise ordering or state. Batch windows compete with reconciliation and regulatory jobs for resources. Test backpressure and queue growth with realistic data size and distribution.

Define a deadline for a response. After a payment action is taken under fallback, a late model result is evidence for analysis, not a new execution instruction. For a batch output, a missed publication deadline may trigger use of an approved prior snapshot or manual review. Customer and operations teams need an accurate status, not a hidden delay masked as processing.

Failure modes

A source partition can stop delivering while other partitions continue. An event schema can change without breaking parsing but alter category meaning. A streaming consumer can replay messages after recovery, double counting if it lacks idempotency. A batch extract can be complete in row count yet omit a high-value segment. A feature store can serve a cached value beyond its freshness limit. A policy API can time out after a model responds. Each failure requires monitoring at the relevant layer and a defined operating action.

Use fault injection in a safe environment. Drop a source partition, duplicate events, delay a reference update, corrupt a field, restart a stateful consumer and fail the evidence sink. Observe feature values, model outcomes, policy actions and customer-facing statuses. The goal is not merely to restore the pipeline; it is to account for decisions made during the defect.

Design backfill carefully. Replaying missed events can repair current feature state and historical analytics, but should not re-execute old payments or create duplicate cases. Separate data recomputation from business command execution. Record original and corrected values, affected decision IDs and remediation actions. A pipeline that becomes green after replay can still have produced harmful decisions during the gap.

Data quality and governance

Put checks at intake, transformation, feature, score and output stages. Verify schema, key uniqueness, partition arrival, control totals, join cardinality, feature validity, score range, policy status and final-action reconciliation. Use thresholds tied to use-case risk. A missing mandatory screening input should not be treated like an optional marketing feature. Make rejected or quarantined records visible and route them to an owner.

Track lineage across both real-time and batch paths. For each decision, retain source references, data versions, feature snapshot or reproducible reference, model version, policy version, fallback state and final action. A batch run additionally needs its cutoff, input manifests and publication approval. Protect sensitive customer data through scoped access and retention. A correlation ID without actual source-version meaning is insufficient for replay.

Operational metrics should link technical health to decision outcomes: source lag, state completeness, model-request rate, fallback rate, queue age, customer holds and later fraud or credit outcomes. Some labels mature slowly, so do not infer that a new pipeline is safe from one hour of low confirmed loss. Use leading data-quality indicators and later outcome review.

Payment scenario

At 09:00, a payment hub receives a new-beneficiary transfer. A streaming counter shows three distinct outgoing instructions in the prior hour; a daily batch baseline provides typical transfer amount. The feature response carries event watermark, batch version and missingness states. The fraud model produces a score, and the policy service applies a threshold plus independent rules. A hold is recorded in the case tool and customer status.

At 09:05, the daily baseline batch is discovered to have omitted accounts migrated overnight. The affected population query finds decisions that consumed the incomplete baseline. The bank invokes an approved fallback for future payments, preserves previous decision records and reviews actual holds or releases. A corrected batch run is published with a new version. It does not overwrite the evidence of the 09:00 decision. The incident review compares corrected scores, policy effects and customer outcomes.

At 09:10, the streaming counter lags on a separate partition. The model API still responds quickly. A freshness gate detects the stale counter and routes those requests according to policy. The two incidents require distinct scope and response. An aggregated "pipeline available" metric would miss both.

Credit scenario

A monthly portfolio model scores accounts as of the last business day. The batch job freezes eligible facilities, joins customer and product references as of cutoff, computes cash-flow and arrears features, and reconciles record counts and balances. The model output is reviewed and published for account-management decisions. A changed loan status code after migration increases unmatched records. The run fails its quality gate and is not published. The previous output may be used only if its age and intended use remain approved.

A rerun after mapping repair carries new input and code versions, with a documented comparison to the blocked run. Business owners inspect segments whose scores changed. The bank retains both run artifacts for audit, but only the approved result flows to decisions. This is a batch fallback: control the release of a whole population, not merely a single API call.

Acceptance exercise

Select one real-time instruction and one batch-scored facility. Trace each from source to action, including event and processing times, input versions, feature computation, model and policy. Inject a duplicate event and a missing source partition into the first path; inject an incomplete customer mapping into the second. Verify detection, fallback, affected-population identification, safe replay and final reconciliation.

The architecture is ready when the bank can explain which facts were available at each decision deadline, how it knew inputs were sufficiently fresh and complete, what action occurred during failure, and how it corrected affected outcomes without rewriting history.

Ordering and lifecycle semantics

An event stream can preserve order within a partition but not necessarily across all services. A payment status may reach the feature job before the original instruction due to retries or separate topics. Define how the consumer handles an unexpected transition: buffer for a bounded time, quarantine it, or reconstruct from the authoritative payment record. Do not silently accept an impossible status sequence. Record the event's source sequence and ingestion time so investigators can distinguish a late event from a business reversal.

Out-of-order events affect rolling features. Suppose a transfer initiated at 10:00 arrives in the stream at 10:05, after a second transfer was scored at 10:03. An offline rebuild by event time may include the first transfer in the second decision's prior window, but the live model never saw it. Preserve what the feature service actually returned and its watermark. A corrected analytical feature can estimate impact, while the original record explains the decision. If late arrival is common, redesign the source path or adjust the policy rather than pretending the issue vanishes in replay.

Batch ordering also matters. A nightly pipeline should not publish an output before every required upstream file reaches its declared cutoff. A late reference extract can give half the population a new mapping and half an old one. Freeze versions in a run manifest and fail the run on unexpected changes. If a source provides corrections during the run, decide whether to restart with a new cutoff or complete the frozen snapshot and address the correction separately.

State, snapshots and replay

A streaming feature store needs an initial state. Loading a snapshot and then applying changes requires a handoff point so no update is lost or counted twice. Capture the snapshot watermark and verify continuity of event offsets. On restart, test the same procedure with realistic volume. A cache that warms gradually may return missing features for the earliest live requests. The approved startup mode should account for that population.

Retain enough source events and schema versions for the required replay window. Retention is a governance choice shaped by law, privacy and operational need; indefinite copying of raw customer data is not automatically justified. If full raw replay is not possible, preserve decision-time feature snapshots or protected references sufficient to explain past actions. Test retrieval of an older decision after the transformation code has changed.

A batch snapshot should include the list or manifest of source partitions, record counts, checksums or control totals, reference versions and quality results. Reproducibility means a reviewer can identify the inputs and computation that produced the published file; it does not require unsafe duplication of all sensitive data. A corrected run should link to the prior run and explain changes in population, features and action recommendations.

Training pipeline design

Training pipelines differ from decision pipelines because they join later outcomes. Separate the feature observation cutoff from the label observation window. A payment fraud training set might use information before authorization and a later confirmed fraud outcome. A credit set might use application-time features and default within a defined subsequent horizon. Ensure labels are mature and handle unresolved or unobservable cases explicitly. The training job should not expose outcome fields to the feature builder.

Use entity- and time-aware splits. Random rows from the same customer, facility or fraud network can appear on both sides of a split and exaggerate generalization. Validation should include later periods and meaningful stress segments. Record source extract, feature definitions, cohort and exclusions. A model trained on a polished historical batch must be tested against the actual live feature availability and missingness profile.

Retraining is not the automatic remedy for every pipeline alert. If a mapping bug corrupts a feature, first correct the source and assess decisions. Training on corrupt data may make the model accommodate an error without fixing customer impact. If genuine behavior changes, collect mature outcomes and evaluate candidate models under the updated distribution. Keep the data-quality and model-change decisions distinct.

Operational handoffs

The source team owns the event and business meaning; the platform team owns delivery and transformation; the feature team owns online and offline calculation; the model team owns validated inputs and score behavior; the policy owner owns final action; operations owns incident response. A single alert may cross all of them. Runbooks should say who declares a data-quality incident, who can activate fallback, who identifies affected decisions and who communicates with customers.

Define a completeness watermark for each published dataset and a freshness status for each critical online feature. Dashboard users should know whether counts are final, provisional or under backfill. Management reports and model monitoring should not treat a partial day as a complete period. A late batch can be a reporting issue even if the live decision service remains healthy; a live feature outage can be urgent even if the next batch report will eventually reconcile.

Release changes through a controlled comparison. A new event schema, partitioning scheme, feature transformation or model endpoint can change decisions. Run a representative shadow path, compare source coverage, feature vectors, scores and policy outcomes, and inspect outliers with domain owners. Shadow traffic should not cause duplicate business actions. Rollback should name compatible data and model versions, not just an earlier container image.

Security and privacy

Streams and batch tables can expose account identifiers, payment narratives, bureau attributes and case notes. Segment access by purpose. A feature service can return derived values without exposing full source narratives to every model developer. Training extracts should be governed, de-identified where feasible and retained only as required. Audit logs should preserve enough references for authorized replay while avoiding uncontrolled copies of raw customer information.

Protect event ingestion against malformed or malicious content. A payment reference may contain text intended to manipulate a downstream LLM used for case summarization. Treat source text as untrusted data and keep policy instructions separate. Validate schemas and lengths, log rejects, and test retrieval and generation boundaries. A streaming pipeline that delivers data faithfully can still deliver adversarial content.

Encryption, service identities, key rotation and access logs should cover both real-time and batch paths. A backup or replay environment needs the same governance as production. If a vendor participates in serving or data transport, verify contractual evidence, incident notification and data handling relevant to the bank's use. Availability design without confidentiality and integrity controls is incomplete.

Quantitative service targets

Set end-to-end targets based on the decision. A real-time path can measure percentage of eligible requests scored with valid current features within the deadline, plus tail latency, fallback rate and reconciliation to final actions. A batch path can measure complete input population at cutoff, quality-gate pass rate, publication time and number of corrected reruns. These metrics should have denominators and time windows. Reporting only endpoint uptime omits stale-data decisions.

For a queue, monitor oldest item and age distribution as well as total depth. A small queue containing a few overdue high-priority payments can be serious. For a stream, measure lag of critical partitions and state restoration progress. For batch, track the latest approved output age and the effect of missed runs. Attach thresholds to operating decisions and escalation owners.

Review these targets after incidents. If a supposedly acceptable five-minute lag caused false holds during peak payments, the freshness limit was not fit for that use. If a batch cutoff routinely excludes a late region, adjust the source contract or publication schedule. Targets are evidence-based assumptions about how the pipeline supports banking decisions, not decorative numbers.

Independent review questions

Can the team identify every payment scored with a stale stream partition? Does the batch manifest prove which accounts were eligible at cutoff? Can an older decision be replayed from the feature and policy versions actually used? Do retries preserve one business action? Does a failed quality gate prevent publication or activate the documented limited mode? Can a source correction be backfilled without sending a second payment or overwriting the original decision record?

Answer these with records from fault drills and real sampled decisions. The pipeline's purpose is to produce timely, trustworthy inputs and accountable actions. Its design is proven at the boundaries where time, data and policy disagree.

Worked reconciliation

Imagine a morning window with 10,000 accepted payment instructions. The hub reports 9,700 settled, 200 held for review, 50 rejected by deterministic checks and 50 still pending. The model service records 9,900 successful scores, 60 timeouts and 40 invalid-input responses. These numbers should not be forced into identical buckets: some rejected instructions may never be eligible for scoring, and a retry may create more than one model attempt. The reconciliation design maps each unique instruction to its eligibility, request attempts, final score or fallback, policy action and terminal or pending status.

The analyst first checks whether all 10,000 instruction IDs appear in the decision journal. Then the analyst groups by actual path and explains the 100 unsuccessful model requests. Were the 40 invalid inputs referred, rejected or processed under a documented rule? Did the 60 timeouts invoke fallback before the deadline? Did any late scores arrive after settlement, and were they prevented from changing the action? The 50 pending items require an aging report and owner. A simple equality between model-call count and payment count would be wrong because retries and pre-score validation exist.

At the next cutoff, compare the hub's settlement and return events with ledger postings and case dispositions. A settled payment can later return, so status counts change over time. Preserve the first decision and each later lifecycle event. If a backfill produces 50 previously missing source records, update analytical aggregates and review affected feature snapshots, but do not generate 50 new payment commands. The audit trail should distinguish processing repair from customer action.

This exercise should be automated where possible and sampled manually for unusual paths. Its output is a list of specific unmatched or inconsistent IDs, not merely a 99.9 percent success badge. Reconciliation turns a collection of functioning services into a bank process whose decisions can actually be accounted for. The business owner should sign off unresolved exceptions with an explicit deadline and customer-impact assessment. The next run should confirm that the exceptions were resolved without silently excluding their source population.

Publication and serving boundary

A nightly customer baseline is due at 02:00, while a streaming counter updates through each payment event. At 02:05 one source file is missing. The batch run must remain unpublished or carry an explicitly approved partial state; the online payment service should continue only with feature combinations validated for that condition. A fast model response does not make a stale baseline current.

At 02:30 the missing file arrives and a new batch run passes reconciliation. Publish it atomically with a run ID and cutoff. Sample live requests before and after publication to confirm which baseline version each consumed. A historical rebuild may include events unavailable during an earlier decision; retain the original live feature snapshot. This scenario tests two clocks, the quality gate, version routing and recovery without duplicate payment actions. Inject a technical retry during the publication switch. The hub must retain one business instruction and the feature service must identify which baseline version the request consumed. Reconcile both model attempts to the same final action, and prevent late batch correction from being presented as information known at the first decision.