Industry / Financial services
Data and AI for financial services builds reporting and analytics that can be explained and audited, not just displayed. Quorlytic ties every reported figure to a traceable calculation and source, designs access around regulatory obligations rather than convenience, and reconciles a workflow before any automation is layered on top of it.
By QuorlyticUpdated
In financial services the question is rarely whether a number can be displayed; it is whether the number can be explained. Definition, transformation, source, effective date, entity and control are what make a figure defensible — and they are architecture decisions, not reporting features.
Lifecycle
The path a reported figure takes from an event to a signature. Institutions differ in how these stages are organised and named; the stages themselves are what every review asks about.
Define the measure before it is built
Revenue, exposure, arrears and capital are each several measures wearing one word. The definition states calculation, grain, period basis and exclusions, with an owner who resolves disputes.
Capture the transaction as it happened
Events enter through core systems, payment rails, brokers and documents, each with its own identifiers, posting rules and timestamps. Event date and posting date begin to diverge here.
Post, match and reconcile
Entries are matched across systems and against external statements. Breaks, suspensions and reversals are normal; the question is whether they are visible and owned.
Aggregate across entities and hierarchies
Exposure, liquidity and customer value are aggregated across legal entities, portfolios and product hierarchies that do not share one key or one reporting calendar.
Investigate what the signal does not explain
Alerts, anomalies and unexplained movements go to a person. The useful design keeps the evidence next to the alert, so the review is an investigation rather than a search.
Support the decision, keep the judgement human
Risk, credit and pricing decisions consume model and analysis output, but the authority for a consequential decision stays with a named role and is recorded.
Report on a defined cut-off
Management, regulatory and financial reporting each run to a cut-off, a basis and a sign-off. Late corrections have to be attributable to the period they belong to rather than folded into today.
Attest, review and improve
Reporting is signed, reviewed and questioned. The review is where data architecture is either proven or exposed: a figure that cannot be rebuilt on request fails at this stage, not the previous one.
Where it breaks
Four failures explain most of the distance between a reporting pack and a defensible number.
A measure is implemented in the reporting layer, sometimes in several places, so the same figure can differ between a management pack, a regulatory return and a dashboard.
What it costsReviews become reconciliations between reports, and the organisation spends its control budget explaining differences rather than managing risk.
Backdated corrections, restatements and late entries overwrite the value that was reported at the time, leaving no record of what was known when.
What it costsReported figures change without explanation, and a reviewer cannot reconstruct what the position actually was on the reporting date.
Transformation logic is documented in code and spreadsheets but not connected to the report line a reviewer asks about.
What it costsEvery question becomes an investigation, and the answer depends on who is available to remember how the number was built.
Entitlement is applied in the reporting tool, while the underlying model holds every entity and every record for everyone.
What it costsAccess testing is unreliable, sensitive data reaches places it should not, and the control cannot be evidenced.
Functions
Five functions, each owning a question that a data architecture either answers or cannot.
| Function | The question it owns | Data it needs | Analytics | Decision |
|---|---|---|---|---|
| Risk & capital | Where is risk concentrated, and can the number be defended? | Exposure by counterparty and product, collateral, limits, model output with version, hierarchy mappings | Risk aggregation across entities, concentration and limit analysis, scenario comparison | Reduce, hedge, hold or escalate exposure |
| Finance & reporting | Can this reported figure be reproduced on request? | Ledger balances, adjustments, effective-dated records, reconciliation evidence, lineage to source | Reconciliation, variance analysis, restatement attribution, control testing | Report, adjust, restate or remediate the control |
| Financial crime & investigations | Which activity requires investigation, and what evidence supports it? | Alert records, transaction history, counterparty and network context, prior dispositions, policy thresholds | Alert prioritisation, network and pattern analysis, case outcome tracking | Escalate, clear or close with a recorded reason |
| Credit & lending | What evidence should support this credit decision? | Income and cash-flow data, exposure history, collateral, behavioural signals, policy rules and overrides | Affordability and behavioural scoring, policy-rule evaluation, override monitoring | Approve, price, decline or refer with an accountable owner |
| Customer & distribution | Which customers or products need attention, and why? | Relationship and product holdings, servicing history, interaction records, consent and entitlement context | Value and attrition analysis, servicing pattern analysis, next-best-action support | Serve, retain, reprice or withdraw a proposition |
Decisions
Four decisions, each traced from the question to the measurement — including what the analysis does not settle.
Data required
Analytics
Decision
Which case is escalated, which is cleared by rule, and which needs a person now
Measurement
What this does not settleThis does not determine guilt, and it does not replace the investigator's judgement or the institution's policies. Ranking changes the order in which cases are examined, not the standard they are examined against — and a control that cannot explain why a case was cleared will not survive review.
Data required
Analytics
Decision
Where exposure is reduced, hedged or escalated, and on what reported basis
Measurement
What this does not settleAggregation is only as defensible as the mappings underneath it. Where entity structures, netting eligibility or model assumptions are disputed, the honest output is the range those choices produce — not a single figure presented as the position.
Data required
Analytics
Decision
Approve, decline, price or refer — with a named owner and a recorded reason
Measurement
What this does not settleNo model decides this alone, and this page does not describe autonomous lending. The analysis supplies evidence and consistency; the authority, the rationale and any exception to policy stay with an accountable person and a recorded process.
Data required
Analytics
Decision
Report, adjust, restate or remediate the control — with the reason recorded
Measurement
What this does not settleTraceability is not the same as correctness: a figure can be fully traceable and still wrong because a definition or a mapping is wrong. This map establishes that a review can be answered; whether the answer is defensible remains a question of definition, policy and judgement.
Illustrative interface
A reference interface, not a Quorlytic product and not a client screen. It shows the shape of the screen a review would be answered on: one row per report line, with its reconciliation state, effective dating and trace path. No figure here is a result.
| Report line | Latest source | Effective date | Reconciliation | Trace |
|---|---|---|---|---|
| OK: Net interest income · entity A | Core banking · ledger 04 | 31 Aug 2026 | Balanced to ledger | Definition · mapping · source |
| Watch: Expected credit loss · portfolio 12 | Risk engine run 2026-08-30 | 30 Aug 2026 | Model rerun pending | Model version · assumptions · inputs |
| Risk: Fee and commission · entity C | Posting-date adjustment | Backdated to 31 Jul 2026 | Break open · 2 items | Adjustment · period · approver |
| OK: Customer deposits · group | Party master · hierarchy v6 | 31 Aug 2026 | Balanced to sub-ledger | Hierarchy · conversion · source |
| Watch: Operational loss event | Case management · 1 new this period | 27 Aug 2026 | Awaiting classification | Case · policy · classification |
Data foundation
The foundation exists so that a figure can be followed backwards. It keeps parties and accounts distinct, preserves value, posting and effective dates, converts currency on a stated basis, and attaches lineage and entitlement to the data rather than to the report.
Source systems
Regulated records with different books, clocks and owners. The ten systems are enumerated in the inventory below.
Ingestion
Late and amended records handled as normal, not as incidents
Cloud platform
One reconciled history, with the as-was view kept
Identity & hierarchy
Who the counterparty is, and where it sits
Controls & lineage
Evidence a reviewer can follow
Risk & finance models
Comparable across books and periods
Decision surfaces
Where committees and controllers work
Action
Never an automated credit or trading decision
Three conventions carry most of the weight: value date recorded separately from posting date, hierarchy and reference data kept with effective dates rather than overwritten, and lineage generated by the pipeline rather than drawn by hand. Without them, every review becomes a reconstruction. For a reported balance, business intelligence reconciliation defines the metric and reporting grain; when source systems are being replaced, data modernization planning must preserve the effective-date history those checks depend on.
Posted balances, account and product identity, value and posting dates
Check before trustingPosting-date records that cannot be re-stated to the value date they belong to
Transaction events, settlement positions, reversals and chargebacks
Check before trustingReversals that arrive after the period closes and are absorbed into the current one
Legal entity, party and relationship hierarchy, with effective dates
Check before trustingHierarchies restated in place, so historical aggregation cannot be reproduced
Alerts, case records, dispositions, threshold and rule versions
Check before trustingDispositions stored without the rule version that generated the alert
Applications, approvals, repayment schedules, arrears and forbearance
Check before trustingPolicy overrides recorded in free text where they cannot be monitored
Exposure, limit, model output and the assumptions behind a run
Check before trustingReruns that overwrite previous output without version history
Adjustments, accruals, intercompany positions and period close
Check before trustingManual journals that reach reporting without an attributable period
Investigations, evidence, correspondence and approvals
Check before trustingEvidence held in documents that cannot be linked to the record under review
Reconciled history, effective-dated models and the lineage between them
Check before trustingTransformation logic that exists only in code, disconnected from the report line
Currencies, calendars, counterparty and instrument reference data
Check before trustingReference data refreshed without the vintage that was used at reporting time
Analytics & AI
Each rung is only worth building once the one below it holds. In a regulated estate, skipping a rung is not a shortcut; it is a control that cannot be evidenced.
One definition per measure, reconciled to source, effective-dated, with lineage that a reviewer can follow.
RequiresMetric ownership, effective-dated records and generated lineage
Breaks, adjustments and restatements surfaced with their cause, their period and their owner.
RequiresValue and posting dates preserved, plus attributable adjustment records
Concentration, limit and sensitivity analysis on aggregated data that ties back to source.
RequiresHierarchies with effective dates and documented aggregation bases
Alerts and cases ranked by consequence, with the evidence attached where the decision is made.
RequiresDispositions recorded with rule versions and a reason code that means one thing
Retrieval and summarisation over permitted documents and records, with citations and a refusal path, kept inside entitlement.
RequiresPermission-aware retrieval, approved corpora and evaluation of refusals as seriously as answers
Maturity
The label matters less than the readiness test: it says what has to be true before the next stage is worth attempting in a reviewed environment.
Each report implements its own definitions; lineage is reconstructed by the people who built the report.
Ready for the next stage whenA measure has one owner and one definition outside the reporting layer
Definitions, lineage and reconciliation are in the platform; adjustments carry their period and approver.
Ready for the next stage whenA reviewer's question about a figure is answerable from the platform, not from memory
Controls, access and issue tracking attach to the data and the figure it supports rather than to the pack.
Ready for the next stage whenControl evidence can be produced for a specific report line on request
Risk, investigation and customer decisions consume governed data with human authority and recorded rationale intact.
Ready for the next stage whenOverrides, model versions and outcomes are monitored as part of the control environment
Measurement
What a financial institution should measure, and which decision each measure informs.
| Measure | What it captures | Decision it informs |
|---|---|---|
| Report-line traceability | Share of report lines traceable to source without manual reconstruction | Where lineage or modelling has to be completed before the next review |
| Reconciliation break rate and ageing | Breaks open, by value and age, and how long they stay open | Which break needs escalation rather than another day of matching |
| Adjustment and restatement volume | Corrections by period, cause and approver | Whether the cause is upstream data, a definition or a control |
| Time to reproduce a figure | Effort and elapsed time to answer a reviewer's question | Where lineage, documentation or access must improve |
| Access exceptions | Entitlement failures found in testing with real identities | Whether access is designed in the platform or assumed in the tool |
| Data quality by critical element | Accuracy, completeness and timeliness for the elements that feed reporting | Which source or control to remediate first |
| Model and rule version coverage | Share of outputs stored with the version and assumptions that produced them | Whether a decision taken last quarter can be explained today |
| Investigation queue health | Case age, volume against capacity, and reopen rate | Whether to change detection rules or add investigative capacity |
These are measures an institution would track for itself, with the reading most teams give them. They are not results Quorlytic has produced, and definitions vary between institutions, between entities and between reporting bases.
Principles
Reporting figures must reconcile to source systems and carry an owner. Agree definitions for revenue, exposure and risk measures before building views. Preserve the calculation, the period and the exclusions so a reported value can be traced and defended.
Regulatory and internal controls determine who may see which data. Carry roles, retention and audit requirements into models and reports. Test row-level access with the identities that will actually consume the output, not a demonstration account.
Engagement
A sequence that starts with one reported figure and ends with a reviewed decision path, without claiming to deliver a regulatory programme in one step.
Choose one figure
OutputA single reported measure with its consumers, disputes and review history, chosen because it matters
Trace what exists
OutputA lineage map from report line to source, with the gaps and manual steps named rather than hidden
Agree the definition
OutputOne owned definition with grain, period basis, exclusions and an approver
Rebuild the path
OutputPipelines and models that produce the figure from source, with effective dating and generated lineage
Attach the controls
OutputReconciliation, access testing and evidence linked to the figure rather than to the pack
Extend deliberately
OutputThe next figure, entity or decision promoted on the same pattern, with the control evidence carried forward
Where this connects
Effective-dated models, reconciliation and generated lineage — the path a figure travels
Risk, investigation and customer analysis with model versions and overrides recorded
Model deployment, evaluation and monitoring in an environment where every output may be reviewed
Permission-aware retrieval over policy, procedures and case documents, with citations and refusals
Ownership, monitoring and incident response for the pipelines a reporting calendar depends on
How a definition becomes something a build fails on rather than something a report reinterprets
Permission-aware retrieval over controlled documents, and where retrieval fails
Evaluating retrieval and answers separately, which is what a reviewed environment requires
Knowing a feed stopped versus knowing the values in it are wrong
Ownership, policy and lineage as architecture rather than as a catalogue nobody maintains
Questions
A bounded, read-only workflow can start once source ownership and access rules are clear. Broader reporting or automated decisions should wait until definitions and controls are agreed.
Detection can be automated; the consequence usually should not be. Automated scoring or alerting is common, while blocking a customer, closing a case or escalating an investigation stays with a person who can see the context. Keep the decision boundary explicit and test the false-positive cost against the team that handles the alerts.
Your next data decision
Bring the business question.
We'll help shape the engineering brief.
