Why Fintech Can’t Afford “Approximately Correct” Data

“Close enough” is a harmless phrase until money is involved. In fintech systems, small data mismatches rarely announce themselves. They pass tests, slip through releases, and surface later as reports that won’t reconcile or access that quietly widens.

Kostiantyn Shkliar brings 10+ years in software development and QA across reliability work and enterprise CRM, with experience at Rozetka.ua, DöhlerGroup, EXANTE, and EPAM Systems. As of 2024, he works as a Senior Salesforce QA Automation Engineer in the U.S. fintech sector, designing automation and data protection strategies for Salesforce ecosystems supporting asset scale exceeding $130 billion.

Below, he explains where “approximately correct” begins, why relationship-level errors slip past black-box checks, and how white-box validation, hybrid validation layers, and JSON-driven scenario factories help teams confirm system state through frequent releases.

Q: You’ve said, “Data is the new currency, and accuracy is its exchange rate.” What does that mean in fintech day to day?

Kostiantyn Shkliar: Data drives decisions and controls behavior. It shapes what customers see, what employees can do, and how transactions move through a system.

Accuracy determines whether data is usable. Slightly wrong data becomes unreliable, even when everything looks stable. Dashboards load and workflows complete, but risk grows when stored state no longer matches the rules the business depends on.

Q: Your career spans SRE work, automation engineering, enterprise CRM, and fintech platforms. What shaped your focus on data accuracy and consistency?

Kostiantyn Shkliar: Early work in reliability taught me to think in failure modes and recovery discipline. Later, in fintech and enterprise CRM, I saw how data moves across APIs, integrations, workflows, and security layers. A release can look fine while underlying state becomes less consistent over time.

I also spent several years at EPAM Systems designing Salesforce- and Vlocity-based solutions for large international clients. Enterprise platforms accumulate configuration and exceptions. If validation doesn’t keep pace, the meaning of the data can shift without anyone noticing.

Q: When you say fintech can’t afford “approximately correct” data, what does that look like inside enterprise systems?

Kostiantyn Shkliar: It’s usually a mismatch that looks small until it spreads.

A record can exist but be linked to the wrong parent entity. That breaks rollups, reporting, segmentation, and automation. Outcomes become harder to trust.

Security drift is another example. A permission set change can expand access in ways teams didn’t intend. UI checks can still pass while the access model changes underneath.

That’s why I focus on relationships. In CRM systems, relationships represent ownership, rules, and financial meaning.

Q: You’ve described black-box testing as ineffective in modern cloud architectures. Why does that approach fall short?

Kostiantyn Shkliar: Black-box testing validates user flows through inputs and outputs. It’s useful for basic checks, but in large cloud platforms the output on a screen can come from changes across multiple components and integrations.

Surface checks can miss internal inconsistencies. A release can “work” while the system state becomes less consistent over time. White-box validation addresses that by checking data states inside the architecture, not only what the UI displays.

Q: For readers outside QA automation, what is White-Box Data Validation in practical terms?

Kostiantyn Shkliar: It’s validation from the inside, focused on system state.

• Data model consistency: Objects, relationships, and state transitions behave as intended.
• Metadata correctness: Configuration stays coherent and avoids risky drift.
• Access model correctness: Permission sets, object access, and field-level security stay aligned with governance rules.
• Scenario correctness: Workflows produce the right data states, beyond UI-level checks.

I build validation using .NET 8.0 and C# for API and metadata checks, with Salesforce knowledge including SOQL, SOSL, object relationships, and permission models.

Q: You built a Hybrid Validation Engine that reduced regression testing time from 60-plus hours to 2–3 hours. What problem were you solving?

Kostiantyn Shkliar: Release confidence at enterprise scale.

Regression becomes expensive when you need to verify many dependencies and scenarios. The Hybrid Validation Engine made data checks a fully automated cycle. At a large U.S. financial institution, it reduced regression testing time from 60-plus hours to 2–3 hours.

“Hybrid” means multiple validation layers working together. It checks APIs, metadata, and data states across realistic scenarios. One layer alone misses too much in complex CRM architectures.

Q: You’ve said you “test relationships” and use JSON-Driven Data Factories. How do they work, and why do they matter?

Kostiantyn Shkliar: Test data becomes brittle when teams hardcode records and manually set fields.

JSON-Driven Data Factories model scenarios as structured definitions. You describe a scenario in JSON, generate the data in a controlled test environment, and reuse it across validation layers.

This scales scenario coverage without using production data or manipulating databases directly. You validate chains of relationships that mirror real workflows, which makes tests more meaningful and less fragile.

Q: Security and governance are constant concerns in fintech. How do you approach preventing data leaks inside Salesforce ecosystems?

Kostiantyn Shkliar: Security comes from layers working together like permission sets, object access, field-level security, role hierarchy, and how automation interacts with configuration.

Those layers change frequently. Small changes can accumulate into unintended exposure. I treat access control checks as part of validation, with automation that reviews security configuration continuously so drift is caught early and changes remain auditable.

Q: You advocate for clean code and architectural transparency. Why does simplicity matter in validation systems?

Kostiantyn Shkliar: Validation is only useful when teams trust it.

Complex validation logic becomes hard to review and maintain. Readable code is easier to audit, extend, and keep consistent across teams. In fintech systems, clarity supports reliability.

Q: You’ve talked about autonomous, self-correcting data systems. As of 2024, what does that direction look like?

Kostiantyn Shkliar: A system detects anomalies early, fixes low-risk issues automatically, and escalates high-risk issues with clear context.

The path includes monitoring configuration drift, validating critical relationships continuously, and detecting security changes that deviate from governance rules. This depends on strong validation foundations and visibility into what changed and what it affects.

Q: If a fintech team wants to reduce “approximately correct” data, what should they change first?

Kostiantyn Shkliar: Define what “correct” means in a way you can verify. In Salesforce environments, that often comes down to relationships, security rules, and key transaction states.

Then make correctness testable at the architectural level. UI checks catch surface problems. They rarely prove the internal state stays consistent after workflows, integrations, and metadata changes.

Build a small library of scenario definitions for high-risk workflows so teams stop relying on hand-built test data that varies from person to person.

Treat access control as part of data quality. In fintech, “wrong” includes “visible to the wrong person.” Automating permission and configuration checks reduces drift and supports auditability.

Editor’s Note

In large fintech CRM environments, costly issues often stay quiet. They show up as relationship mismatches, gradual security drift, or configuration changes that shift outcomes over time. Shkliar’s approach focuses on proving system state, not only passing UI checks.