A data product is an operating commitment
A new lake or warehouse gives an institution a place to hold data. A trusted data product gives a consumer a dependable way to use it. The difference is a defined population, business meaning, accountable ownership, quality expectations, access rules and a support arrangement that survives the initial project.
Servicing organizations often have multiple versions of loan status, delinquency and payment history across the servicing system, vendor workflows, finance extracts and analytics stores. Consolidation can make those differences more visible. It cannot decide which definition is right for each use.
Henna83's recommendation is to build products around consequential decisions. Begin with a specific consumer and ask what they must decide, how quickly, with what history and what consequences if the data is wrong. This approach avoids creating a large catalogue whose assets have no committed use.
Three decisions come first: appoint a business owner with authority over meaning, define the product contract with the consumer, and fund ongoing quality and support. Engineering owns implementation. The business remains accountable for the rules that make the output useful.
Start with one decision and one accountable consumer. Design the product contract before expanding the catalogue.
Evidence favors value and ownership
Deloitte reports that 55% of respondents to its 2025 Tech Value survey invest in data modernization [1]. The investment figure does not show whether those organizations created dependable servicing products. Henna83's implication is that the investment case needs a named consumer outcome and the cost of maintaining it.
The Basel Committee's January 2026 BCBS 239 implementation discussion reinforces the continuing importance of bank data governance [2]. Its original focus on systemically important banks must not be represented as a universal mortgage-servicer obligation. The useful operating principle is to connect accountable governance with the quality of data used for decisions.
For covered servicing activities, Regulation X includes objectives relating to timely and accurate information [3]. A product serving a borrower-information or investor-reporting flow should therefore connect the approved business requirement to the source, transformation and output evidence. Client legal and compliance teams determine applicability.
A product investment should capture both benefit and maintenance burden. Additional data sources can add value, but also create schema dependencies, permission questions and new exception paths. The product owner must decide which expansions justify that cost.
Published governance principles inform the design. The product contract must still fit the institution's own use and responsibilities.
Where trust breaks in servicing data
Population breaks occur when two teams use different loan universes. Active, transferred, paid-off and charged-off accounts can enter or leave a report under different rules. State the population and effective date alongside every product metric.
Definition breaks occur when a familiar term has several legitimate meanings. Days past due may depend on transaction timing, reversals or the particular business purpose. Preserve the rules and source event dates, not just a final indicator.
History breaks occur when ingestion overwrites prior values without retaining the state that supported an earlier report. Decide what history is needed to reproduce important decisions, then implement retention and versioning appropriate to that purpose.
Ownership breaks occur when a consumer finds an error and no team can authorize its correction. A platform team can repair a pipeline but may not be authorized to change the business classification. Define a joint triage path with an accountable business owner and engineering responder.
Consumption breaks occur when a product exists but reports and vendors continue using ungoverned extracts. Migration of consumers is part of product delivery. Record each consumer's acceptance and retire duplicate feeds only after their replacement is proven.
Architecture context: a product can be delivered as a table, API, event stream or controlled extract. The consumption need determines the interface. Preserve identifiers and effective dates across layers so that a consumer can understand corrections. Separate an authoritative source from a derived measure. A derived measure may be useful and approved without becoming the master record for every business purpose. Document the route by which consumers request a definition change.
Exhibit: the servicing data-product contract
Complete this canvas before developing a new product. It creates a decision record that engineering, business consumers and control owners can review together. The canvas is an original Henna83 working framework.
| Contract element | Question to resolve | Evidence |
|---|---|---|
| Purpose and population | Which decision and which loans? | Consumer-approved use statement |
| Meaning and history | What do fields mean over time? | Definitions and version policy |
| Service level | How fresh and available must it be? | Agreed refresh and support targets |
| Quality and exceptions | Which failures block consumption? | Rules, tolerances and exception route |
| Ownership and access | Who decides, supports and may use it? | Owner, steward and approved access |
| Value and retirement | What changes and what feed stops? | Baseline, adoption and retirement plan |
Using the canvas: meet with the first consumer and complete the purpose and population fields before choosing the interface. Test the contract against three events: an upstream delay, a disputed definition and a permission change. Confirm who acts in each case. The contract is incomplete if the service expectation has no funded support owner. Maintain versions so that later consumers can see which promises they are accepting.
Acceptance requires consumer use and support ownership, in addition to a successful pipeline.
Worked example: a delinquency product
Illustrative scenario, not a client result. Collections, finance and analytics all use a delinquency field. Collections needs current operational status. Finance needs a controlled period-end population. Analytics needs point-in-time history. One unqualified column cannot safely serve all three purposes.
The design starts with common source events and loan identifiers. It then defines separate approved measures or views for each purpose, with effective dates and lineage. The business owners agree how reversals, transfers and timing differences are handled. Engineering implements those definitions and retains the versions needed to reproduce results.
The product includes a freshness indicator and known exceptions. A late upstream file should make a freshness gap visible; it should not silently present yesterday's value as current. A quality rule identifies impossible date sequences and routes them for review without inventing a correction.
Success is measured through accepted use: the operational team uses the agreed current view, finance can reproduce its close, and analytics understands historical state. Any reduction in rework is measured from an actual baseline. The institution should avoid claiming savings from a product merely because it has been published.
Questions for the CDO: Which products have committed consumers? Which definitions are disputed? Can the consumer distinguish current data from stale data? Who owns the funding and quality work when the initial program ends?
Common sources can support different approved measures. Shared governance should preserve the distinctions that matter.
Build the first product and its support model
First month: choose a product with a committed consumer, complete the contract, establish source-to-output lineage and baseline the current manual work. Identify material definition disputes and assign decision owners.
Next phase: build the minimum usable product, test important events and agree the support handoff. Record the version, approved access and known limitations. Move the selected consumer onto it and monitor actual use.
Scale only after the team can demonstrate freshness, quality, acceptance and exception response for the initial product. Reuse the contract and technical patterns where they fit; do not force every domain into identical latency or history requirements.
Measure consumer adoption, unresolved definition disputes, exception age, refresh compliance and duplicate feeds retired. Savings require evidence that work or cost was removed, with finance agreement where financial claims are made.
Use the CDO Operating Model Starter and Data Discovery & Readiness Kit to establish the first product boundary. Henna83 connects consumer requirements, data architecture, governance and delivery so that the product becomes part of the operation. Let's talk about the decision your data needs to support.
Measurement detail: count adoption only when the consumer has accepted and uses the product for the defined purpose. Distinguish known defects from missing quality coverage. Report freshness breaches with the affected population and time window. Verify duplicate-feed retirement before recognizing benefit.
References
[1] Deloitte Insights. Valuing data assets can be key to unlocking board-level support for data modernization and transformation. December 5, 2025. https://www.deloitte.com/us/en/insights/topics/digital-transformation/valuing-data-assets.html
[2] Basel Committee on Banking Supervision. Implementation of the Principles for effective risk data aggregation and risk reporting (BCBS 239 Principles). January 6, 2026. https://www.bis.org/publications/implementation-principles-effective-risk-data-aggregation-and-risk-reporting-bcbs-239-principles
[3] Consumer Financial Protection Bureau. 12 CFR 1024.38: General servicing policies, procedures, and requirements. Current online regulation checked October 10, 2026. https://www.consumerfinance.gov/rules-policy/regulations/1024/38/