DEV Community: RWaltz Software

AI Clinical Documentation: What Ambient Scribes Change and What They Do Not

RWaltz Software — Thu, 24 Sep 2026 10:44:19 +0000

The better the scribe gets, the weaker your safety net becomes

Every vendor answers the accuracy question the same way, and the answer is correct: the clinician reviews the note and signs it. Attestation is the control this whole category rests on.

It is also a control that weakens in proportion to how good the tool is. People are poor at sustained detection of rare errors in output that is nearly always right. The pattern shows up wherever automation is mostly reliable, in aviation, radiology assistance and driver support systems: as the failure rate falls, the human checker stops finding the failures that remain. Not through carelessness, but because vigilance for rare events is something humans do badly and cannot be trained out of.

So a scribe that is right ninety five percent of the time gets read carefully, and one that is right ninety nine percent of the time gets skimmed. The number of errors reaching the permanent record may not improve at all.

This is not an argument against the technology. It is an argument that the engineering problem is not where most people are looking.

Which is why vendor accuracy benchmarks mislead

Accuracy measured on a generated note, before a human touches it, is the wrong denominator. What matters is the error rate in signed notes, which is a product of model accuracy and review effectiveness, where the second term falls as the first rises.

Ask for that number instead. Most vendors will not have it, because obtaining it means auditing signed notes against what actually happened. That absence is worth knowing before a contract is signed.

Two follow up questions reveal more than a headline figure. Which specialties, accents and interpreter mediated consultations was the evaluation run on, and does that include your population? And how does performance trend over months in a deployed site rather than an evaluation set?

Review is worst at catching exactly the errors that matter

Not all errors are equally detectable, and the split is not random.

Errors that look wrong get caught. A garbled sentence, a drug name that makes no sense, a date that cannot be right, each of these interrupts a reader and gets fixed.

Errors that look right do not, and in clinical documentation those are the dangerous category:

Invented negatives. A symptom recorded as absent when it was never asked about. Nothing in the text signals a problem, because thorough documentation looks exactly like this.
Fabricated normal findings. Examination elements the model expects to accompany a complaint, generated because they usually appear rather than because they were performed.
Attribution drift. A condition described about a parent during family history, recorded as the patient's own.
Plausible dose errors. A strength or frequency that is wrong but inside the range a reader accepts without checking.

Each reads as competent documentation. The reviewer's attention is a filter tuned for implausibility, and these pass straight through it.

Design for review, not for generation

If review is the control, review is the thing to engineer. These are interface decisions rather than model decisions, and they are where a custom layer earns its cost.

Keep notes short. Length is the enemy of scrutiny, so verbosity is a failure mode rather than a feature.
Separate what was said from what was inferred, so a clinician sees at a glance which statements carry interpretation.
Mark low-confidence passages rather than presenting uniform prose. Uniform confidence is a lie the output tells about itself.
Link each assertion back to its moment in the encounter, so a doubtful line takes seconds to check rather than requiring recall.
Do not autofill sections that were never discussed. An empty examination field is safer than a populated one nobody performed.
Instrument the review, and alarm on it

Model accuracy is the wrong thing to monitor in production. Review behaviour is the leading indicator, and your own systems already measure it.

Track the time between a note being presented and signed, the proportion edited before signature, how much changes when edits happen, and the distribution across individual clinicians. Establish the pattern in the first weeks, while people are still reading carefully, and treat a later collapse in sign off latency as the signal it is.

That is the alert worth building. Not a drop in model performance, which you will not see, but the moment your organisation stopped checking.

Two others matter. Billing level distribution, because models write thorough sounding notes, thorough notes support higher levels of service, and drift stays invisible until an audit finds it. And a periodic human audit of signed notes against the clinician's recollection, the only way to get the number that counts.

Audio is protected data, and consent is not a checkbox

Ambient capture creates a recording before it creates a note, and that recording is a separate risk.

Establish in the contract whether audio is retained at all, for how long, who at the vendor can access it, and whether your recordings or the resulting notes train their models. Consultation audio is protected health information, so a business associate agreement is required in the United States and an equivalent arrangement elsewhere, and it does not transfer your obligations. The safest default is processed and discarded.

Consent has a wrinkle specific to this setting. Some jurisdictions require the consent of everyone recorded rather than one party, and a consultation room holds people who were never asked: family members, carers, interpreters, sometimes another patient audible beyond a curtain.

Independent security review should cover the capture path, the storage and the record system integration, not the model alone.

Where a distributed ledger does not help

We build blockchain systems, so this is worth stating plainly. The pitch that surfaces here is an immutable record of consent or note provenance, and it misreads the requirement twice.

Clinical records must be amendable. Corrections, addenda and late results are routine, and regulations generally require a record can be changed with the change and its author visible. Immutability works against that, and record systems already keep audit trails regulators accept.

The hard part of consent is obtaining it meaningfully from everyone in the room and honouring a withdrawal across every copy of the data. That is a process problem, not a storage problem.

Buy the engine, build the layer that protects you

For most organisations the engine should be bought. Vendors have speech models tuned to clinical vocabulary, certified integrations with the major record systems and validation work that is expensive to replicate, and building to parity is a poor use of budget.

What is worth building is everything in this article: the review interface, the instrumentation, the audit sampling, the monitoring that tells you when checking stopped. Those are specific to how your clinicians work, no vendor will prioritise them over their own roadmap, and they separate a deployment that is safe from one that merely looks safe.

If you commission that work, hold the pipelines, configuration and documentation at the end, with another team able to operate it without the original supplier. A control you cannot inspect is not a control.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps, and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories, and intellectual property; engagements are scoped honestly, including the cases where buying is the better answer; and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/ai-clinical-documentation-what-ambient-scribes-change-and-what-they-do-not

Connect with RWaltz:

LinkedIn: https://www.linkedin.com/company/rwaltzsoftware
X (Twitter): https://twitter.com/rwaltzsoftware
Facebook: https://www.facebook.com/RWaltz-Software-PvtLtd-255590135349493
Telegram: https://t.me/RWaltzCrypto
GitHub: https://github.com/rwaltzsoftware
Clutch: https://clutch.co/profile/rwaltz-software
Website: https://www.rwaltz.com

AI Solutions for Telecom: Where Operators Get Value and Where They Take Risk

RWaltz Software — Tue, 22 Sep 2026 11:17:51 +0000

You are the account recovery system for the rest of the economy

A phone number resets a bank login, an email account, a payroll portal, and a crypto exchange. Whatever else an operator sells, it also operates the credential that most of the internet falls back on when everything else fails.

That makes one control decisive: who is allowed to move a number to a new SIM or a new provider. A fraudulent SIM swap hands an attacker the passcodes for accounts an operator has never heard of, and the loss lands on a bank, an employer or a customer rather than on the operator that approved the change.

Now consider what most operators are deploying this year: an AI assistant in the care channel that can act on accounts. If it can be talked into a SIM change, a port authorisation, an address update or adding a line, it is a social engineering target that never gets tired, works at scale, and reads instructions from whatever a customer types into it.

That is the risk worth leading with, because it is specific to telecom and it is being built right now.

Score informs, authentication authorises

The principle is short enough to put in a design document.

A model may rank a SIM swap request as suspicious using signals an operator holds: a device seen for the first time, an unusual location, recent account changes, the channel the request arrived through. That score should route the request, add friction, or trigger a hold. It should never be the thing that approves the change.

Approval comes from authentication performed outside the model, through a channel an attacker is unlikely to control, which specifically rules out a passcode sent to the number being taken over. Identity-sensitive actions run from an explicit allowlist; every one is logged, and anything outside the list goes to a person. The assistant drafts, retrieves, and summarises; it does not hold authority over identity.

This is the same separation that belongs in any system where a model sits near something valuable: the component that proposes and the component that authorises are not the same component, and the second one is auditable.

Two things extend the principle. The identity checks an operator already performs at SIM registration, under know your customer rules in many markets, are the enrolment side of the same control, and an automated channel that can bypass them is a gap rather than a feature. And the signal is worth sharing: operators increasingly expose SIM swap and number verification checks to banks through network APIs, so a bank can pause a large transfer when the number behind it changed SIM an hour ago.

Sort every use case by what it is allowed to change

Widen the same question across the rest of the estate. Every telecom AI use case sits at one of three levels of authority:

Advisory. A person acts on the output: a churn list, a fraud alert, a proposed root cause.
Gated. The system acts within limits and asks for approval outside them.
Closed loop. The system changes the production network with no person in the path.

Customer analytics mostly sits at the first level, where an error wastes a retention budget. Network automation is moving toward the third, where an error affects every customer on the cells it touches, emergency calls included.

Closed-loop systems need a bounded blast radius, meaning few sites at first and hard limits on how far any parameter can move, automatic rollback when service indicators degrade, change records like any change an engineer makes, and a stop mechanism that still works while the automation platform itself is failing.

They also need to be treated as privileged infrastructure. A platform with write access to network configuration is a high value target, so its credentials deserve the handling you give privileged human access, and independent review should cover that platform and its integrations rather than the model alone. In the EU, AI used as a safety component in managing critical digital infrastructure is classed as high risk, with those obligations applying from December 2027 following amendments adopted in 2026. Whether a given system qualifies depends on what it controls, so classify use case by use case.

The value is in a join nobody wants to fund

Operators can measure something no other industry can: the calls that dropped, the sessions that failed and the throughput each customer actually received, at the places and times they used the service.

Every distinctive telecom AI use case depends on connecting that to the customer. Experience-driven churn, proactive service recovery when a known fault has affected someone, prioritising capital investment by revenue at risk rather than by cell utilisation, all of it needs network data keyed to cells and network elements to meet customer data keyed to accounts and contracts.

That join is an engineering project with no demo, and it is the thing most AI proposals assume already exists. It is also where the legal work lives, because traffic and location data carry rules specific to electronic communications on top of general data protection law, and a churn model may need a basis that network operations never did.

Scoping honestly means saying this at the start. If the join does not exist, the first phase builds it, and a vendor who prices a model on top of data nobody has inspected is transferring risk to the buyer.

Where a distributed ledger does not help

We build blockchain systems, so this is worth stating plainly. The pitch that recurs here is decentralised identity on a ledger, offered as the fix for exactly the SIM swap problem above.

It misreads where the failure is. Numbers get stolen through social engineering of retail staff and contact centre agents, insider access, and weak recovery flows. None of that is a defect in the credential format, and a ledger does not make a persuadable human harder to persuade. Self-custodied credentials also make recovery harder rather than easier, and the people most often targeted by SIM swap are not the people best placed to keep a recovery phrase safe.

Fix enrolment, authentication, and staff authority first. If there is still an identity problem after that, it will be a different one.

What you should hold at the end

If someone builds this for you, the deliverable is not a model file. It is the feature definitions, the pipelines that produce the join, the guardrail configuration, the evaluation design, and the documentation of limitations.

The build-to-own principle matters more here than in most industries. A system that scores SIM swaps or adjusts live network parameters will be asked about by a regulator, a bank, or an incident review, and an operator that cannot explain, revalidate, or retrain it without the original supplier has put a dependency inside a control it is accountable for.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories and intellectual property; engagements are scoped honestly, including the cases where a simpler approach is the better answer, and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/ai-solutions-for-telecom-where-operators-get-value-and-where-they-take-risk

Connect with RWaltz:

Blockchain in Banking and Finance: Where It Works and Where It Does Not

RWaltz Software — Fri, 18 Sep 2026 10:04:42 +0000

Banking runs on two properties a ledger deliberately removes

The first is settlement finality that holds in law, not only in code. The second is the ability to undo a mistake.

Both are absent from a blockchain by design, and both are non negotiable for a regulated institution. So every bank deployment reintroduces them, and reintroducing them means reintroducing an authority with powers to intervene, which is precisely what the architecture was meant to remove.

Not fatal. Plenty of worthwhile systems sit at that compromise. But it changes what you are building, and it is better said on day one than found at legal review.

Finality on a chain is not finality in law

Settlement finality in conventional systems is generally statutory. Designated systems benefit from protections making settled transfers legally irreversible even through an insolvency, which is what allows institutions to treat them as done.

A transfer confirmed on a chain resembles this technically and has a legal status that varies by jurisdiction and arrangement. Whether it is protected, and from what moment, is a question for counsel in each relevant jurisdiction, and the answer decides whether the bank can treat it as settled for accounting, risk and regulatory purposes.

Confirm it before design is fixed. A system that technically settles but does not legally settle creates an exposure the risk function will refuse, and engineering cannot close that gap afterwards.

Errors have to be recoverable

Operational banking assumes mistakes are fixable. Payments get recalled, misdirected funds returned, duplicate instructions reversed. Dual control exists because people make errors.

So every deployment needs a documented mechanism for handling an erroneous transfer, and every such mechanism creates an authority able to move value it does not own. Who holds it, what constrains it, its approval path and how its use is logged are first order design questions, not hardening steps.

Across several institutions this is a governance negotiation before it is a technical design. Settle it in a document, then check the deployed permissions match line by line.

Subtract what banking already fixed

Much of the original pitch has been overtaken. Instant payment schemes settle domestic transfers in seconds in most developed markets, through infrastructure operated by a party all participants accept. Settlement cycles have been compressed. Messaging standards carry richer structured data.

For domestic payments the condition that makes a shared ledger valuable, the absence of an operator everyone trusts, is simply not present. The scheme operator is trusted by regulation and by design, so a proposal to replace it should explain what it adds. Usually the honest answer is nothing.

The one real gap is programmability, payments conditioned on events. Whether that justifies the architecture depends on how much of your volume needs conditional execution, and for most banks it is a small fraction.

Cross border is where the diagnosis still holds

A cross border payment often traverses several correspondent banks, each running its own compliance checks, holding pre funded accounts in the other's currency, keeping its own record. The sender frequently cannot see where the payment is or when it will land.

The cost is not processing. It is liquidity trapped in pre funded accounts, reconciliation labour across institutions, and exception handling when a payment stalls, all of it flowing from every participant keeping a separate record of the same transaction.

That is the shape a shared ledger addresses, and it still turns on whether the participating banks will accept a common operator. If they will, a shared scheme database achieves much of the same result. If they will not, because of competitive sensitivity about who sees which flows, a permissioned design becomes genuinely relevant rather than decorative.

Collateral mobility is the quiet one that pays

The strongest wholesale case gets the least attention because it is unglamorous.

Collateral posted against margin and repo obligations often takes a day or more to move between custodians and jurisdictions, so institutions hold buffers against the delay. Moving it in minutes reduces the buffer, freeing capital that sits idle for operational rather than risk reasons.

The benefit is measurable, the participants are a manageable number of sophisticated institutions rather than a long tail, and the trust boundary is real because no single custodian should control the register. That combination is rare here.

Know which instrument you are holding

A tokenized deposit is a commercial bank liability on a ledger. The holder has a claim on the bank, inside the regulated perimeter, with whatever protections that carries.

A stablecoin is a claim on its issuer, backed by that issuer's reserves, under whatever framework applies. Credit risk, redemption mechanics, regulatory treatment and the holder's position on issuer insolvency all differ.

Any proposal using the terms interchangeably has not worked through the balance sheet consequences, which makes it a useful early filter on vendors and internal business cases alike.

The gates that kill projects regardless of merit

Capital treatment. How the exposure is classified determines what the bank holds against it. Frameworks distinguish tokenized traditional assets meeting certain conditions from other exposures, with materially different consequences, and the area has been moving. If holding the instrument is capital punitive, the case fails before anyone assesses the technology.

Custody and key management. A private key is a bearer instrument, which sits badly against operational norms built on reversibility, dual control and named accountability. Institutional custody means hardware or MPC-based key handling, separation of duties between whoever deploys and whoever controls value, documented rotation and offboarding, and recovery tested before launch rather than designed during an incident. This is usually the hardest internal conversation, well ahead of the contract work.

Third-party dependency. Resilience obligations require banks to manage and evidence their dependencies, and one on a public network or node provider is hard to discharge, because no counterparty is accountable for availability. This shapes network choice as much as any technical factor.

Compliance runs through all of it. Transfers must carry originator and beneficiary information, screening must happen before value moves, and permissionless transferability conflicts with both. Standards for permissioned instruments exist for this reason, and eligibility logic belongs inside the token rather than beside it.

Where it does not belong

Trade finance is the instructive failure. Several high-profile consortium platforms wound down after substantial investment, and the reason was not engineering. The underlying problems are document fraud, credit assessment on unfamiliar counterparties and sanctions screening, none of which sharing documents on a ledger addresses. A fraudulent bill of lading recorded immutably is a fraudulent bill of lading every participant can now rely on.

The second reason is network effects. A platform is useful only once your actual counterparties have joined, and reaching that point is commercial field work rather than development. Most ran out of funding first.

What you should hold at the end

Independent security review should cover key custody, the off-chain services and the integration points, not only the contracts, and repeat after every change to deployed logic.

On ownership: the client holds the keys, repositories, deployment scripts, infrastructure and documentation, with another team able to operate the system from that alone. A bank that cannot operate or audit a settlement component without its original vendor has created a third-party dependency inside a regulated process, which is the problem it was told to manage.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories and intellectual property; engagements are scoped honestly, including the cases where an existing scheme or a shared database is the better answer; and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/blockchain-in-banking-and-finance-where-it-works-and-where-it-does-not

Connect with RWaltz:

Blockchain for Supply Chain: What It Can and Cannot Prove

RWaltz Software — Wed, 16 Sep 2026 13:34:05 +0000

Sort the claims before you scope

This category makes a handful of standard promises. Some are physically impossible, one is marketing, and a few produce numbers a finance director can check. Sorting them before anyone scopes a build is most of the work, and the step usually skipped.

The distinction underneath all of it: a ledger gives strong assurance that a record has not been altered since it was written, and none that the record was true when written. Every claim below either survives that sentence or does not.

Fails: proof of origin

Take coffee. Cherries from many smallholder farms go into the same fermentation tank and dry on the same beds. Lot identity is destroyed by the process itself, before any software is involved. Tracking a blended commodity back to one farm is an approximation by construction, and calling it proof overstates what exists.

Even without blending, the binding between a physical thing and its record is made by a person or device at the point of entry. Scan the wrong pallet, attribute a delivery to the wrong plot, and the ledger preserves that error permanently with excellent cryptographic assurance.

An incentive problem comes with it. Accurate entry requires whoever enters it to have a reason to be accurate, and if the premium for verified provenance is captured further up the chain, the person recording the delivery has no stake in getting it right.

Fails: counterfeit prevention

Serialization verifies that a code is valid and legitimately issued. It does not verify that the package contents correspond to it.

A counterfeiter who copies a valid identifier onto falsified packaging passes verification until the same code appears twice in circumstances that cannot both be true. Detection is statistical and after the fact rather than preventive. Still useful, and much weaker than stopping counterfeits entering the chain. Design and describe the system on the weaker claim.

Fails: consumer transparency

A code that opens a supply chain map does not tell a consumer whether the claims are true. It tells them a record exists and has not been edited, which is not what they are invited to conclude. That is marketing, and there is nothing wrong with marketing: fund it from the marketing budget rather than presenting it internally as the business case for traceability.

Pays: recall precision

This is the case that consistently survives scrutiny.

When a defect is found, recall cost depends on how precisely the affected population can be identified. A manufacturer who can show which lots went to which distribution centres, and which cases were aggregated onto which pallets, recalls a narrow slice. One who cannot recalls everything.

The requirement is accurate aggregation data maintained consistently across parties, which is achievable and measurable. Unlike most traceability claims it produces a number you can estimate in advance and check afterwards, needing no origin claim at all.

Pays: certified volume integrity

Because segregation is expensive, most certification in agricultural commodities runs on mass balance: certified inputs and outputs reconciled by volume rather than kept physically separate. A processor buying certified beans may sell an equivalent quantity as certified without those specific beans staying distinct.

This gets treated as an embarrassment. It should not be. Mass balance is a reasonable response to a physical constraint, and it has one specific failure mode: selling more certified output than certified input supports.

That is exactly what a shared ledger handles well. Certified volume becomes a balance that can only be debited by what was credited, enforced across participants who each see their own position rather than everyone else's trading data. Less exciting than proof of origin, entirely achievable, and it addresses a weakness paper based schemes struggle with.

Pays: reconciliation and dispute evidence

Two companies keeping separate records of the same shipments spend real money reconciling them and arguing about differences. A shared record both parties wrote to removes the argument rather than resolving it, and payment can trigger on verified delivery events instead of manual matching.

Cold chain monitoring belongs here rather than under prevention. A sensor can be detached, spoofed, badly positioned or fail, and an immutably recorded excursion is still an excursion that does not stop the goods shipping. The record settles who held the product when conditions breached limits, which has real value in liability allocation and insurance.

The test that decides whether you need a chain

Ask whether any participant could operate the system with the others accepting it. If yes, a conventional database with signed records, strong access control and periodically published hashes gives tamper evidence far more cheaply and with less governance overhead. A large share of deployments described as supply chain blockchains are single-operator systems with a ledger attached for the narrative.

The genuine trust boundary, where it exists, is usually not fraud. It is that trading relationships and volumes are commercially sensitive, and no participant wants a competitor or an interested central operator seeing who buys what from whom. That points toward permissioned designs with selective disclosure, and it is worth testing before committing.

The alternatives deserve a fair hearing. A shared database run by an industry body or neutral third party is mature and already behind several large traceability systems in production. Point-to-point exchange using shared standards works for chains with few participants. And physical audit addresses the data entry problem no digital system solves, which is why audit plus digital records beats either alone.

We build blockchain systems, so weigh that. Where a single operator is acceptable and standards are agreed, the database is the better answer.

Standards first, then keys at the edge

Most of the value in traceability comes from agreeing on identifiers and event semantics across participants. That agreement needs no ledger, and without it no amount of distributed consensus makes incompatible records comparable. Standards adoption comes first; the ledger is a later decision.

Then key management, which in a multi-party network is the weak point rather than a detail. Each participant signs attestations with their own keys, so a compromised key anywhere produces forged records the network preserves permanently and treats as authentic. Devices in warehouses and at collection points are the real attack surface, not the consensus layer.

The design needs rotation and revocation that work in the field, a defined correction path for records written in error or under a compromised key, and independent review covering edge devices and enrolment rather than only the contracts. Under a build-to-own arrangement, the client holds the keys and infrastructure at the end, because a network run on your behalf by a vendor has relocated the single operator problem rather than solved it.

Onboarding is the project

The cost of a multi-party network is dominated by getting participants to use it correctly. Smallholders, contract manufacturers, third-tier suppliers and logistics providers each need identifiers, devices, training, support in their own language and a commercial reason to bother.

Budget for field work, incentives, hardware and support, which usually exceed the software cost and continue after launch. Settle governance first: who joins, who pays, who reads what, how a disputed record is corrected, what happens when a participant leaves. Then check the deployed permissions match it.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories and intellectual property; engagements are scoped honestly, including the cases where a shared database is the better answer, and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/blockchain-for-supply-chain-a-business-guide-to-what-it-can-and-cannot-prove

Connect with RWaltz:

How to Choose an AI Development Company: A Buyer's Checklist

RWaltz Software — Tue, 15 Sep 2026 13:44:40 +0000

Nearly everything you evaluate is easy to manufacture

Case studies, client logos, team biographies, framework lists, a tidy portfolio page. All of it can be assembled by a firm that has never put a model into production or had to explain why one stopped working.

The signals that cannot be manufactured require having failed at something. A vendor who has watched a project stall knows where projects stall, and that shows up as specific, uncomfortable answers. A vendor who has only closed deals produces smooth answers with no edges.

Five questions separate the two, and none are about model architecture.

What would make you decline this work?

Ask it directly in the first conversation.

A vendor with a real answer names conditions: not enough labelled outcomes, no reliable way to measure whether it worked, no capacity to act on predictions, an unsettled regulatory position, or data that cannot be reconstructed as it stood when decisions were made. Each of those answers comes from having seen it sink something.

A vendor who cannot name one has no standard, and will not apply one to your project either. You find that out at the point where someone should have said stop.

A related test costs nothing: include a requirement that is slightly wrong and see whether they push back. Agreement with everything is not flexibility, it is an absence of opinion, and opinions are most of what you are paying for.

What happens in the first two weeks?

Good answers start with data: whether the outcome variable exists and is recorded reliably, how much history is available, whether features can be reconstructed as they stood when a decision was made rather than as they look now, and whether the predicted events are captured anywhere at all.

Weaker answers start with architecture, model families or platform decisions. Those matter later and none are knowable before anyone has examined your data. A proposal naming the model before the data assessment is describing a preference.

What result would count as this not having worked?

This is the question most proposals cannot survive, and the one to be least flexible about.

Before any build begins, the proposal should state what success means, what the baseline is, and how the comparison will be made. Baselines carry the weight. An accuracy figure with nothing to compare it against is not evidence, and on rare outcome problems a model predicting that nothing happens will post an excellent number.

Press for specifics. Current performance of whatever is being replaced, measured the same way. Whether there will be a holdout, a control group, or a period running alongside existing practice without influencing decisions. How degradation gets detected, and at what threshold someone acts.

A vendor who cannot describe a disappointing outcome has not designed an evaluation, and a project that cannot fail cannot be shown to have succeeded.

Who acts on the output, and how many can they handle?

A prediction does nothing by itself. Someone has to behave differently because of it.

Establish who, how many cases they can work in a day, how fast they can act, and what they will do. That capacity sets the operating threshold, which determines what performance actually needs to be. A model tuned to a threshold nobody can staff is tuned to nothing.

A vendor who raises this in the first meeting is thinking about outcomes. One who defers it to implementation plans to hand over a model and leave.

What does year two cost?

Models degrade. Data drifts, processes change, regulations move, and a retrained model is a different model needing revalidation.

Ask who retrains and on what trigger, whether monitoring is included and who watches the alerts, what a regulatory change costs when it forces a modification, and what three years total looks like including your internal effort. A build price with no ongoing view is either incomplete or assumes you will return without leverage.

What belongs in the contract rather than the conversation

Technical proposals get scrutinised. Terms get skimmed, and they are easier to negotiate before work starts than after.

Ownership of the model, code, feature definitions, pipelines and documentation. A model file alone cannot be retrained or revalidated, so owning the artefact without the pipeline is not ownership of anything useful.
Whether your data, or anything derived from it, may improve the vendor's other work. Ask explicitly and put the answer in writing.
Sub processors. If the vendor sends data to a hosted model API, that provider sits in your data flow, needs approval, and belongs in your privacy notices. It is regularly discovered afterwards, which is how a delivered project becomes a compliance problem.
Data handling during development. Where it lives, who can access it, whether access is logged, whether the work can run on masked or sampled data, and a dated deletion commitment.
Exit. Could another team operate the system from documentation and tests alone.

The principle worth requiring of any supplier, including us, is that you end up able to operate, audit and change what was built without the original vendor in the room. Where the system handles sensitive data or makes consequential decisions, independent security review belongs inside the engagement rather than as an optional line item, covering the surrounding services and not only the model.

Sequence it so you can stop

The strongest protection is not a clause, it is an order of operations.

Scope and pay for the data assessment as a separate first phase with a genuine option to stop. It costs a fraction of a full build, answers the questions that determine viability, and lets you watch how the vendor works before committing to the rest. If it concludes the project should not proceed, that is a good result cheaply obtained.

Fixed pricing a full build on data nobody has examined transfers risk to whoever is least able to price it, which is usually you.

When the answer is not a vendor at all

An honest checklist has to include this, because for many use cases custom development is the wrong purchase.

A mature domain product may already encode years of refinement your build would start without. An internal hire can be better value for ongoing work, since they accumulate context a vendor has to be paid to rebuild each engagement, though a team of one is fragile. A foundation model API with light engineering covers classification, extraction and summarisation cheaply, trading off cost at volume, latency, non determinism and your data travelling to a third party. And often the constraint is a process gap or no capacity to act, in which case fixing that removes the problem.

The same test applies to our field. We build blockchain systems, and for most prediction problems, fraud scoring, churn, clinical risk, credit decisioning, a distributed ledger contributes nothing. If a vendor proposes bundling one into an analytics project, ask what it solves. If the answer is portability, auditability or trust, ask why a database with signed logs and proper access control does not cover it. Usually it does.

Apply all of this to us as readily as to anyone else. A supplier who objects to being evaluated this way has answered a different question.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build to own model: clients hold their keys, repositories and intellectual property, engagements are scoped honestly including the cases where a simpler approach or a different supplier is the better answer, and review is treated as continuous rather than a single sign off.

📖 Read the full blog: https://www.rwaltz.com/blogs/how-to-choose-an-ai-development-company-a-buyers-checklist

Connect with RWaltz:

AI for Loan Default Prediction: How It Works and Where It Breaks

RWaltz Software — Mon, 14 Sep 2026 13:29:33 +0000

Your credit model has never met the people you declined

Repayment is observed only for applicants who were approved. They passed your existing policy, so the training data describes the relationship between characteristics and default conditional on having already cleared a cutoff. The model is then applied to everyone who applies, including the population it has never seen.

This is the defining structural problem in credit modelling, and no choice of algorithm addresses it. It is also the one most often handled with a technique that sounds like a solution and is actually an assumption.

What selection actually breaks

Confidence without evidence. The model produces scores for applicants in regions of the feature space where it has no observations. Those scores are extrapolations, and nothing in the output distinguishes them from scores backed by thousands of outcomes.

Validation does not rescue you. The holdout comes from the same approved population, so strong validation confirms the model works on people you already lend to. It says nothing about applicants you do not serve, which is exactly where a policy change would take you.

Inherited judgement becomes fact. The previous policy encoded someone's view of who was creditworthy. The model learns it as an empirical finding, wrong parts included.

It compounds. Each model generation shapes the next set of approvals, which becomes the next training set. The population narrows quietly, and the metrics look fine throughout because they are computed on it.

The standard fixes are assumptions, not evidence

Reject inference techniques assign inferred outcomes to declined applicants through parcelling, augmentation or joint modelling schemes. They are not useless and they are not corrections.

Every one requires assuming something about rejected applicants that the data cannot establish, which is the original problem restated. Document the assumption, run sensitivity analysis across plausible alternatives, and report the range rather than a single adjusted figure. A performance claim resting on an untestable assumption should say so wherever it appears, including in the credit committee paper.

Unbiased information has a price

The only genuinely new evidence about the population you decline comes from approving some of them and observing what happens.

Two practical forms. A small randomised approval band below the cutoff produces unbiased outcomes for applicants just outside current policy, at a cost that can be estimated in advance. And swap set analysis, run whenever policy changes, tracks who is newly approved and newly declined under the new rules and how each performs, which is the closest most lenders get to a controlled comparison.

Neither is comfortable to propose. Both separate a model that can justify expanding the credit box from one that can only confirm it. Frame this as buying information rather than accepting losses, and get sign off at a level that can authorise the spend.

Probability is not the decision

Default probability is one of three components of expected loss. Loss given default depends on security, recovery process and time to recover. Exposure at default depends on product mechanics, particularly on revolving facilities where a distressed borrower draws down before failing.

A well secured loan with a higher default probability can be better business than an unsecured loan with a lower one, and ranking on default probability alone systematically misjudges that comparison.

Loss given default models are usually weaker than default models, because recoveries are lumpy, slow and sensitive to collateral markets. That weakness belongs in pricing and in the model inventory, not blended into a composite number where nobody can see which part is unreliable.

Pricing feeds back into the population

Risk based pricing creates an effect a default model does not capture. When you offer a higher rate to a higher risk applicant, the people most likely to accept are those without better options elsewhere. Acceptance therefore correlates with unobserved risk, and the accepted population at a given price is worse than the applicant population at that price.

Two consequences. Default rates after introducing risk based pricing are not comparable to those before, so a deterioration may be the pricing working as designed rather than a model failure. And portfolio outcomes depend on who is offered what, who accepts and who then repays, so an acceptance view belongs alongside the default model rather than after it.

Lenders who skip this usually find out through slow deterioration in the segments where they priced most aggressively.

Explainability and fair lending constrain model choice

In consumer lending an adverse decision commonly requires specific principal reasons. They must be accurate, stable across similar applicants and defensible, which constrains which models can be used at all rather than being a documentation step afterwards.

This is where the honest comparison sits. Monotonic scorecards, meaning logistic regression over binned characteristics with enforced direction, remain widely used for substantive reasons: reason codes fall out of the structure, monotonic constraints prevent counterintuitive behaviour such as penalising a longer credit history because of a data quirk, and monitoring is direct because a shift in one characteristic's contribution is visible. Gradient boosted models usually deliver better discrimination, typically a moderate rather than transformative gain. Post hoc explanation methods produce plausible reasons, but a reason derived from an approximation of the model is not one derived from its structure, and that distinction matters when a regulator asks how a decision was reached.

Fair lending belongs in model selection for the same reason. Removing protected characteristics is necessary and insufficient, because geography, device signals and name derived features act as proxies. In several jurisdictions the analysis extends to whether a less discriminatory alternative with comparable business results exists, which means searching during development and documenting what was considered rather than testing one candidate at sign off.

One monitoring item usually missed: track underwriter overrides by frequency, direction and subsequent performance. Persistent profitable overrides mean the model is missing something underwriters can see; persistent unprofitable ones are a governance problem. Most lenders do not capture either.

Where a blockchain does not help

Our core business is blockchain engineering, so this is worth saying directly. The recurring pitch in lending is portable credit history on a distributed ledger, or on chain scoring backed by decentralised identity.

It misreads the constraint twice. The barrier to portable credit data is bureau economics, governance and consent, not the absence of a shared database. And credit data must be correctable: consumers have statutory rights to dispute and amend inaccurate information in most jurisdictions with a credit reporting regime. Immutability works against that requirement, and any design has to add a correction layer that ends up being the real system of record.

What the deliverable includes

If someone builds this for you, the model file is the smallest part. The deliverable is the default definition and its documentation, the point in time feature pipelines, the reject inference assumptions with their sensitivity analyses, the fair lending alternatives considered and why they were not selected, and the validation artefacts.

The build to own principle applies here as it does to software. A credit model you cannot revalidate, re explain or defend without the original supplier is a dependency inside a regulated decision affecting consumers, and it will need defending sooner than anyone expects.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build to own model: clients hold their keys, repositories and intellectual property, engagements are scoped honestly including the cases where a simpler approach is the better answer, and review is treated as continuous rather than a single sign off.

📖 Read the full blog: https://www.rwaltz.com/blogs/ai-for-loan-default-prediction-how-it-works-and-where-it-breaks

Connect with RWaltz:

Predictive Analytics in Healthcare: Reducing Readmissions Without Overpromising

RWaltz Software — Fri, 11 Sep 2026 10:46:01 +0000

The score your model produces is protected health information

Most teams treat the inputs as regulated and the output as a byproduct. A readmission risk score attached to an identifiable patient is protected health information, which turns several implementation details into decisions you settle before deployment.

Who can see the score, restricted by role. Whether it goes into the chart, which may place it in the designated record set and within a patient's right of access. How long historical scores are retained. How you would explain one to a patient entitled to see it.

Finding those answers during an access request is a poor time to start. They are cheap to design in and expensive to retrofit.

Purpose and de-identification decide what data you get

Two determinations shape the project, and both belong at the start.

Classification. Using protected health information for treatment, payment, and healthcare operations, which generally includes quality improvement, sits on a different footing from research. If you intend to publish or build something generalisable beyond your own operations, the work may be research and require institutional review board or privacy board involvement. Reclassifying midway is costly.

De-identification route. Safe Harbor removes dates and constrains ages at the upper end, stripping out much of the temporal structure a readmission model depends on. Expert determination is usually the realistic path to usable data, and it produces conditions to honour rather than blanket clearance.

Three further constraints: the minimum necessary standard sits badly with a request for a full extract of everything; any vendor touching the data needs a business associate agreement, which does not transfer your obligations; and some categories carry stricter rules, including substance use disorder treatment records from certain programmes, psychotherapy notes, and individual state requirements. Confirm the applicable set with counsel.

Two reasons the model is weaker than its metrics suggest

You cannot see readmissions to other hospitals. Your record shows returns to your own system, so a patient readmitted to a competitor is invisible and the outcome label is systematically incomplete. The gap is not random: it correlates with geography, insurance type, how mobile a population is, and which facility is nearest in an emergency. A model trained on these labels learns partly about clinical risk and partly about which patients come back to you specifically.

Pursue a health information exchange or claims data through payer partnerships if you can. If neither is available, estimate what share of readmissions the data misses and attach that caveat to every performance figure, including executive slides.

Electronic record data leaks by default. It is generated for documentation and billing, not prediction. The recurring sources: diagnosis and procedure codes finalised at or after discharge, discharge disposition and medications, length of stay computed with the discharge date, and informative missingness imputed away when a test not ordered was itself a signal. Documentation timestamps are not event timestamps either.

The defence is reconstructing every feature as it stood when the prediction is made, from historical snapshots rather than current state tables. One healthcare-specific addition: coding practice varies by site and drifts over time, so a model trained at one hospital often transfers poorly to another in the same system. Validate locally before deploying locally.

Risk is not modifiable risk

Ranking by predicted risk surfaces patients who are sick. The strongest predictors, disease severity, comorbidity burden and prior utilisation, are largely not things a discharge process can change.

What a care transitions programme can change sits further down most feature importance lists: whether medication reconciliation happened, whether a follow-up appointment exists before discharge, whether the discharge summary reached primary care, whether the patient has transport and someone at home.

Use the score to define a candidate pool, then prioritise within it on barriers the programme can address. Pair every flag with the barrier and the action that follows. A number alone produces a phone call; a barrier produces a fix.

Prior utilisation is also where the equity problem lives

Healthcare models have a documented history of encoding inequity through proxies, most clearly when spending or prior utilisation stands in for medical need. Access and utilisation differ across populations for reasons unrelated to illness, so a model trained this way can understate need for groups that historically received less care, then direct resources away from them.

Prior utilisation is also the most powerful predictor available for readmission, which is precisely why this risk is not hypothetical here.

Test performance and calibration by demographic group rather than reporting aggregates, and examine whether the resulting allocation differs from what clinical need would suggest. Removing protected characteristics does not fix this, because correlated features act as proxies.

Clinical ownership and alert fatigue

A risk score influences clinical decisions, so it needs a named clinical owner rather than a data science owner, and its documented limitations should reach the people acting on it. Run the model silently alongside care first, and give clinicians a defined way to disagree on record.

Alert fatigue is a real cost. A score appearing in a workflow without a clear action erodes trust in every other piece of decision support around it. And depending on how the tool functions and how far a clinician can independently review its basis, clinical decision support software can fall within medical device regulation in some jurisdictions. Confirm the current position rather than assuming an internal tool is out of scope.

When not to build a model
The discharge process has known gaps. If medication reconciliation is inconsistent or follow-up appointments are not booked before discharge, fix that first. Universal improvements often beat targeted ones, because targeting is imperfect and the fix is cheap.
There is no transitional care capacity. Without a team to work the list, the model produces a report.
Readmissions elsewhere are invisible, and no data-sharing route exists. You cannot evaluate the programme reliably.
A simple rule performs comparably. Prior admissions in the preceding months are a strong, explainable baseline, easier to govern and cheaper to run.
Where a blockchain does not help

Our core business is blockchain engineering, so this is worth stating directly. The usual pitch here is a distributed ledger for health data exchange, and it misreads the problem. Interoperability is blocked by governance, competing commercial incentives, and consent management, not by the absence of a shared database. Standards and exchange frameworks already move the data.

A ledger does not resolve who may see what, under which legal basis, for how long. Those questions remain exactly as hard, and they are the actual obstacle.

What you should hold at the end

If someone else builds this, the deliverable is not a model file. It is the feature definitions, the point-in-time pipelines, the local validation artefacts, the documented limitations and the privacy determinations made along the way.

The build-to-own principle applies here as it does to software, and matters more in a clinical setting. A model you cannot revalidate, explain, or retrain without the original supplier is a dependency embedded in patient care, and it will need revalidation the first time coding practice or a care pathway changes.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories, and intellectual property; engagements are scoped honestly, including the cases where a simpler approach is the better answer, and review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/predictive-analytics-in-healthcare-reducing-readmissions-without-overpromising

Connect with RWaltz:

Machine Learning for Customer Churn Prediction: What Actually Works

RWaltz Software — Thu, 10 Sep 2026 10:01:52 +0000

Some of your customers are leaving because you called them

A retention call reminds someone their contract is ending. It prompts a price comparison they had not thought to run. It reopens a complaint they had let go. For a slice of your base, being contacted is what triggers the exit.

That group sits on the same list as everyone you intend to save, and a model ranked by churn probability cannot separate them out. This is the flaw at the centre of most churn programmes, and it is not a modelling error. It is a mismatch between the question asked and the question that matters.

The top of your list contains four different people

Rank customers by likelihood of leaving and the top decile mixes four groups sharing nothing but a high score.

Lost causes have already decided and often already signed elsewhere. They score highly and cannot be saved, so the spend is wasted.

Sure things would have renewed anyway, scoring highly for incidental reasons: a billing query, a usage dip, a support contact. Treating them converts full margin customers into discounted ones for no gain.

Persuadables are genuinely at risk and genuinely responsive. They are the only group that pays back.

Sleeping dogs are the group above, made worse by contact.

A probability model ranks all four identically. It was never asked about responsiveness; it was asked who leaves.

Model the difference, not the outcome

The quantity that matters is the change in churn probability caused by the intervention. Learning it requires randomised treatment, because the difference between treated and untreated outcomes cannot be observed in data where a model assigned the treatment.

Two honest caveats, because uplift work is usually oversold. Estimating a difference between two small probabilities is noisier than estimating either one, so it needs more data and more patience. And an uplift ranked list looks unimpressive, because the customers at the top often have moderate churn scores. Someone will ask why the highest risk customers are not being contacted, and you need that answer before the first campaign.

A workable interim step: keep the probability ranked list, randomise treatment within it, and measure the effect by decile. That reveals quickly whether the top of your list responds at all. Frequently it does not, and that finding is worth more than another modelling cycle.

Separate involuntary churn first

A meaningful share of subscription cancellations are involuntary: an expired card, a failed recurring payment, a bank decline. Those customers did not decide to leave.

Leaving them in the training data corrupts the model, since features predicting a card expiry have nothing to do with dissatisfaction. It also conceals an easier win: better retry logic, updating card details before expiry, pre dunning notices and alternative payment methods recover customers with no model involved. If involuntary churn is a large share of your total, fix the payments path first.

The engineering that decides if the model is real

A churn model with a suspiciously strong validation score is almost always leaking. The recurring sources:

Outcome encoding features: cancellation related tickets, a retention offer flag, a downgrade logged inside the cancellation flow, an account status field updated at churn.
Time travel: features computed from data that did not exist at prediction time, usually from joining current state tables instead of reconstructing history.
Aggregates spanning the outcome: monthly usage averaged over a window that includes the final partial month.

The defence is point in time correctness: every feature reconstructed as it stood on the prediction date, using as of joins against historical snapshots. This is unglamorous data engineering, it consumes a legitimate share of the project, and skipping it produces a model that validates beautifully and fails in production. That pattern is also the fastest way to lose confidence in the whole programme.

Metrics that survive contact with a budget

Accuracy is useless on an imbalanced problem, since predicting that nobody leaves scores well. Report instead:

Lift at your actual treatment capacity, the number your team and offer budget can handle, not the cut off that flatters the model
Calibration rather than ranking alone, if you compute expected value, because offer economics need probabilities that mean something
Incremental revenue retained, net of offer cost, the only number the business should judge
Performance by segment, because a model can look strong overall and be useless for new customers, who churn most and have the sparsest history
Give the agent a reason, not a score

A list of identifiers and probabilities produces one behaviour: a generic discount. That is the most expensive intervention available and often the least effective.

Attach a reason in the language of the person doing the work, and map reasons to a playbook. A customer flagged after a billing spike needs the bill explained. One flagged after an unresolved support case needs the case resolved. Money is the right answer far less often than it gets used, and it is what a bare score always produces. That constrains model choice, since reason generation has to be reliable enough to act on rather than trusted because a library produced it.

Protect the holdout or stop claiming results

Treated customers stay at some rate, the rate looks reasonable, and the programme gets declared a success. Most of those customers would have stayed anyway.

A randomised group held back from treatment is the only way to separate programme effect from natural retention. It costs a small amount of churn and it is not optional. There will be pressure to treat everyone, and the moment the holdout disappears the programme becomes unfalsifiable. Re randomise periodically rather than leaving the same customers untreated indefinitely.

When not to build a model at all
Involuntary churn is a large share of the total. Fix payments first.
There is no capacity or budget to treat anyone. A model then produces a report.
Churn has a known cause, such as a service failure or an uncompetitive price in one segment. Fix the cause rather than paying to have it confirmed.
A simple rule using tenure, usage decline and support contacts captures most of the available lift. That is explainable, cheap to operate, and a legitimate permanent answer.

To be direct about our own field: this is a data quality and experimentation problem. A distributed ledger contributes nothing to it, and any proposal combining the two deserves examining for whether it solves anything.

What you should own when the work is done

If someone else builds this for you, the deliverable is not a model file. It is the feature definitions, the point in time pipelines, the experiment design and its logs, the model artefacts and a record of what was tried and rejected.

The same build to own principle applies here as to software. A model you cannot retrain, revalidate or explain without the original supplier is a dependency inside a commercial process, and it will need retraining sooner than anyone expects.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build to own model: clients hold their keys, repositories and intellectual property, engagements are scoped honestly including the cases where a simpler approach is the better answer, and review is treated as continuous rather than a single sign off.

📖 Read the full blog: https://www.rwaltz.com/blogs/machine-learning-for-customer-churn-prediction-what-actually-works

Connect with RWaltz:

AI in Banking: Fraud Detection and Risk Management in Practice

RWaltz Software — Wed, 09 Sep 2026 11:28:53 +0000

Your fraud model is grading its own homework

You only observe outcomes for transactions you allowed. Everything the model blocked produces no label at all, so each retraining cycle learns from a dataset shaped by the model's own past decisions.

The consequence is directional, not random. The model becomes progressively more confident about a world it helped create, and its blind spots persist because nothing in the data ever contradicts them. Credit has the same structure: declined applicants never demonstrate whether they would have repaid, so the scorecard is validated only on the population it already approved.

Most of what matters in bank fraud and risk modelling follows from this problem and the operational limits around it.

Your metrics will not show you this

Precision and recall computed on observed labels can look excellent while the denominator is quietly wrong. Accuracy is worse than useless, since a model that approves everything scores very well on a rare event and catches nothing.

Measures worth reporting instead:

Precision at your actual alert capacity, not at whichever threshold produces the best chart
Value-weighted recall, because a model tuned on case counts will cheerfully miss the expensive frauds
False positive rate per approved transaction, since declined legitimate payments produce complaints and attrition
Alert to case conversion, which tells you whether the model finds fraud or generates work
Label latency, because chargebacks arrive weeks later and recent performance is always partly unknown

Add drift monitoring on the input distribution. It moves before outcome metrics do, and when labels are both delayed and biased, a leading indicator beats a precise lagging one.

Buying unbiased labels

There is no clean fix, only choices somebody has to sign off on.

The direct approach is releasing a small randomised sample below the block threshold, accepting a budgeted loss in exchange for labels not conditioned on the model's own behaviour. It means knowingly allowing some fraud, so it needs explicit approval rather than quiet implementation by the data team.

Partial measures help too. Capture structured investigator outcomes with reason codes rather than chargebacks alone, so a closed alert records why. And retain features as they were at decision time; otherwise your training set describes a state that never existed.

Capacity sets the threshold, not the curve

The operating point is a staffing decision. If investigations can work a certain number of alerts per shift, that number sets your threshold, and every model improvement has to be expressed as more fraud caught within the same budget.

That reframes vendor evaluation. A demonstration at a flattering threshold tells you nothing. Ask for performance at your alert volume, on a period the model was not trained on.

Two things underneath the model that beat model choice

Entity resolution. If the same customer exists as three records across origination, cards, and digital banking, velocity features are wrong, network features are wrong, and investigation is slower. Fixing it usually produces more lift than any change of algorithm.

Network features. Shared devices, beneficiaries, addresses, and phone numbers linking apparently unrelated accounts carry substantial signal, particularly for mule networks. Teams reach for a more complex model when a graph was the better investment.

The latency budget decides the architecture

Real-time authorisation runs on a budget measured in milliseconds, which constrains which features can be computed in the path and how large a model can be.

Three consequences that get discovered late:

Features must be precomputed and served from a low-latency store, which introduces training and serving skew. A model underperforming in production relative to evaluation has usually hit this.
Fallback behaviour needs a documented decision. Defaulting to approve and defaulting to decline are both business decisions with owners and loss implications.
Anything that does not need to sit in the authorisation path belongs in a post-authorisation pipeline with a far larger budget.
Rules deserve more credit than they get

Machine learning versus rules is mostly a marketing frame. Rules are explainable to an investigator and a regulator without extra tooling, change within hours when a new pattern appears, and cost almost nothing to run. They are also brittle and accumulate into unmaintainable estates, which is a real problem rather than a reason to dismiss them.

The part a vendor rarely volunteers: if an organisation has no reliable data pipeline, no entity resolution and no case management workflow capturing outcomes, a well-designed rule engine plus that missing plumbing will outperform a model. Honest scoping means saying so before the statement of work is signed, not in phase two.

AML and credit are governed differently from fraud

Fraud detection protects the institution from loss and can be optimised against a loss curve. AML monitoring discharges a legal obligation, and supervisors expect demonstrable coverage of specified typologies. Using models to prioritise alerts from defined scenarios is broadly accepted and addresses the very high false positive rates typical of rule-based monitoring. Replacing scenario coverage with an unexplainable model is a far harder conversation, and the burden of proof sits with the institution.

Credit adds its own constraint. Adverse decisions affecting individuals commonly require specific reasons, which limits model choice unless reliable reason generation can be demonstrated. Removing protected characteristics from the feature set does not remove disparate impact, because correlated features act as proxies, so test outcomes across groups and repeat after every retraining.

Governance is the actual deliverable

For a regulated institution, the model is a small part of what has to exist: a model inventory tiered by materiality, development documentation covering assumptions and limitations, independent validation by people who did not build the model and can block deployment, monitoring thresholds with escalation paths, challenger models to catch degradation that absolute metrics miss, and change control that treats retraining as a change.

Two points about vendors. A third-party model does not transfer validation, monitoring or accountability, so contractual access to documentation and performance data has to be negotiated before signing. And the build-to-own principle applies here as it does to software: if someone else builds your models, you should hold the training pipelines, feature definitions, model artefacts and documentation. A model you cannot retrain, validate or explain without the original supplier is a dependency inside a regulated process.

Where a blockchain does not help

Our core business is blockchain engineering, so this is worth stating plainly. Fraud detection and risk modelling are data quality and governance problems. Nothing above improves by putting a model or its outputs on a distributed ledger, and any proposal that combines the two should be examined for whether it is solving a problem or adding a technology.

One narrow intersection is real. Fraud signals are more valuable when shared across institutions, and institutions resist sharing raw customer data with each other or with a single operator. Shared registries of confirmed mule accounts sit on that trust boundary. Even there, most working consortia run on conventional infrastructure with a trusted operator, and that is fine. A distributed design earns consideration only when participants genuinely will not accept a single operator, which is worth testing rather than assuming.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps, and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories, and intellectual property; engagements are scoped honestly, including the cases where a simpler approach is the better answer; and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/ai-in-banking-fraud-detection-and-risk-management-in-practice

Connect with RWaltz:

Asset Tokenization vs Traditional Securitization: What Actually Differs

RWaltz Software — Tue, 08 Sep 2026 13:19:35 +0000

A smart contract can pay a waterfall. It cannot create one.

That sentence contains most of what matters in this comparison. Securitization is legal engineering: isolating assets from the originator's insolvency, then dividing the cash flows into tranches with defined priority. Tokenization is a record-keeping and transfer mechanism for whatever interests get issued.

They sit at different layers, so they are not really alternatives. The entire securitization market runs without tokenization, and plenty of tokenized offerings involve no pooling or tranching at all. Where the confusion becomes expensive is the one place the two look identical: a waterfall implemented in code looks exactly like the waterfall described in the deal documents, right up until they disagree.

Four things securitization does that no contract does

Insolvency isolation. Assets move to a vehicle in a way intended to survive the originator's bankruptcy, supported by a true sale opinion. This is what lets an investor underwrite the assets instead of the originator. No register technology produces it.

Legal priority. Subordination, overcollateralization, reserve accounts and excess spread protect senior holders. Priority exists because the documents and the governing law say so, not because of the order of operations in a function.

Ratings, and the capital treatment behind them. For insurers, banks and some pension funds, a rating is not marketing. It feeds their capital rules and determines whether they can hold the paper at all.

Authority when things go wrong. A servicer collects, a trustee enforces on behalf of holders, and reporting obligations are specified. When borrowers stop paying, someone has clear standing to act.

The one thing tokenization does that securitization does badly

Per-investor administration. The register stays continuously current instead of being periodically reconciled. Transfer restrictions are enforced at the moment of transfer using permissioned standards built for regulated instruments, rather than by a manual review that gets compressed at quarter end. Distribution execution to a large holder base gets cheaper. Onboarding infrastructure is reusable across deals.

That is a real improvement and it is narrower than the usual pitch. It does not create insolvency isolation, confer priority, produce a rating, or decide anything about what happens when the assets underperform.

When code and documents disagree, the documents win

This is the failure mode worth designing against, because it is silent.

If the vehicle fails and a court allocates recoveries, it reads the indenture. Meanwhile the contract has been paying according to whatever was implemented, which may reflect an earlier draft, a misread definition of available funds, or a rounding convention nobody discussed. Nothing reverts. Nothing alerts. The wrong parties simply received money for several periods.

Three controls follow:

Derive the contract logic from the executed documents, not from a summary, a term sheet, or a conversation with the structurer.
Review the mapping between documents and code explicitly, as its own artifact. An audit that verifies the code is internally consistent and correct against a spec has not checked whether the spec matches the indenture.
Treat divergence as a defect of the same severity as an arithmetic bug, and reopen the review whenever either side changes. Amendments to deal documents are code changes even when no ticket is filed.

Independent review scope should cover that mapping, the compliance modules, the privileged roles, and the upgrade path, and it should repeat after every change to deployed logic rather than happening once before launch.

Your buyer's capital rules constrain more than your architecture does

A rated senior tranche in a familiar wrapper is holdable by regulated institutional buyers. An unrated instrument recorded on a chain may attract materially different prudential treatment, and in some frameworks the treatment of tokenized exposures depends on conditions the structure has to meet deliberately rather than incidentally.

This is a question for the buyer's regulatory capital team, and it should be asked before the structure is fixed rather than during placement. A related point that rarely comes up early: conventional settlement systems often benefit from statutory finality protections, and whether an on-chain transfer enjoys equivalent legal protection depends on jurisdiction. Confirm it rather than assume it.

Tokenizing does not change the regulatory classification

If a structure pools assets and tranches credit risk, the applicable regime may classify it as a securitization regardless of how ownership is recorded. Depending on jurisdiction, that can bring risk retention requirements, prescribed disclosure, and due diligence obligations imposed on the investors buying it.

Teams occasionally approach tokenization as a way around securitization regulation. It is not one. Establish the classification with counsel first, because it dictates obligations the technology then has to support, including the reporting a regulated investor will demand from you.

Deal size decides this, not technology preference

Securitization carries high fixed costs and a long lead time: legal work, rating fees, trustee and servicer appointments, accountants' procedures, offering documentation. That creates a floor below which deals do not get done regardless of asset quality.

Tokenization has a different cost shape. Lower fixed costs than a rated public deal, and recurring costs securitization does not carry: independent review after every change to deployed logic, key custody arrangements, monitoring, indexing, and daily reconciliation between contract state and the administrator's register.

Compare full multi-year totals rather than a development quote against a legal budget. In practice, the ranking turns on deal size and holder count. A familiar institutional deal with twenty sophisticated buyers gets very little from tokenization and pays for it anyway. A small pool with many holders is where the arithmetic reverses, and it is also the range where full securitization was never economic in the first place.

Keys, roles, and what you hold at the end

Minting, freezing, forced transfer, recovery, and upgrades each need a named holder, a constraint such as a multisig with a timelock, and a written trigger. In a tranched structure, whoever can upgrade the waterfall logic can change who gets paid, which is a control question rather than a technical one.

If a vendor builds it, settle who holds those roles, the upgrade authority, the repositories, the deployment scripts and the intellectual property after handover. Under a build-to-own arrangement, they are yours and another team can operate the system from documentation and tests. A vehicle with a ten-year life is a strange thing to make dependent on one supplier's survival.

When not to do this

If the assets need insolvency isolation, tranching, a rating and an established servicer, you are doing a securitization, and that machine works. Adding a chain to it should require a reason beyond novelty. The reasons that hold up are reaching smaller tickets than the conventional channel supports, or spreading administration savings across a repeated programme. The reason that does not hold up is that the deal would sound more modern.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build to own model: clients hold their keys, repositories and intellectual property, engagements are scoped honestly including the cases where a conventional structure is the better answer, and security review is treated as continuous rather than a single sign off.

📖 Read the full blog: https://www.rwaltz.com/blogs/asset-tokenization-vs-traditional-securitization-what-actually-differs

Connect with RWaltz:

Tokenized Private Credit: A Guide for Institutions

RWaltz Software — Mon, 07 Sep 2026 11:39:59 +0000

Four things must be true before a transfer can clear

Tokenizing private credit is not technically difficult. The difficulty is that a secondary transfer has to satisfy four conditions, and a typical closed-end credit fund fails at least two before anyone writes a line of code.

The transferee must be eligible. There must be a price. The transferee must be able to assume whatever obligations travel with the interest. And whoever holds consent rights must consent.

Software solves the first well and contributes almost nothing to the other three. Working out which tests your structure fails is the scoping exercise.

Test one: is the transferee eligible

This is the part a permissioned token handles properly. Standards such as ERC-3643 pair the token with an identity registry and compliance modules, checking both parties inside the transfer path so an ineligible transfer reverts instead of settling.

For credit funds the rules go beyond KYC and AML status: qualification tests, jurisdiction restrictions, lockups, maximum position sizes, and holder count caps.

That last one matters most. Many private fund structures depend on conditions about the investor base, including limits on the number of beneficial owners. Tokenization tends to increase holder counts, since lower administration cost per investor is one of its real benefits, and that benefit can breach the condition the structure relies on. Encode the caps so a breaching transfer reverts. The thresholds are a legal question differing by jurisdiction, so they belong in the offering documents before a module.

Test two: is there a price

Private credit positions are marked using models, with unobservable inputs, on a periodic cycle, often reviewed by a third-party valuation agent. There is no observable price.

Between valuation dates the only number available is a stale mark, and a great deal can happen between marks: a missed payment, a covenant breach, a deterioration in the borrower's sector. Transferring at a stale mark advantages one side, and if that becomes systematic it is a fairness problem for the fund and a governance problem for the manager.

Every workable approach costs something. Restricting transfers to scheduled valuation dates is defensible and removes most of the liquidity story. Raising valuation frequency improves fairness without making the inputs observable. Negotiated bilateral transfers work between institutions and do not scale. Choose the policy first, then encode it as transfer windows.

Test three: can the transferee assume the obligations

If the interest carries undrawn commitments, the holder does not only own something. They owe something. The fund can call capital, and meeting that call is a question about the holder's creditworthiness.

A transfer therefore moves a liability, and no token standard solves that. The transferee needs a manual credit assessment, the remedies for a missed capital call sit in the partnership agreement and usually involve forfeiture or dilution, and the general partner will keep control over who is allowed in.

Fully funded structures sidestep this, which is why a note issued by a special purpose vehicle is easier to tokenize than a closed-end fund interest. If an offering has unfunded commitments and the pitch involves frictionless secondary transfer, those two things are in conflict, and the conflict is resolved on paper or not at all.

Test four: who has to consent

Partnership agreements typically require general partner consent. Participation agreements require lender consent and often restrict transfer to particular counterparty types. Side letters add constraints that vary by holder.

A contract can gate a transfer on a recorded consent, which makes the control consistent and auditable. It cannot make the decision. Any design assuming transfers clear without a human in the loop needs the governing documents amended first, which is a negotiation with existing investors rather than a technical task.

The structure you choose decides how many tests you fail

A fund interest inherits everything in the partnership agreement: consent rights, capital call obligations, fee terms, the waterfall. It commonly fails tests two, three, and four, and it is the most common structure, which is why so many tokenized fund projects stall.

A note issued by an SPV is fully paid with a defined schedule, so test three disappears and test four simplifies. Pricing remains hard, and you have created a new issuer with its own documentation, servicing arrangements, and regulatory classification.

A loan participation inherits the participation agreement's consent requirements and transfer restrictions, so test four usually binds.

Pick the structure deliberately. It determines the design more than the choice of chain or standard does.

What the contract enforces, and what the administrator keeps

The contract is good at objective checks at the moment of transfer: eligibility, jurisdiction, caps, lockups, transfer windows tied to valuation dates, and gating on recorded consent.

The administrator keeps everything else: interest accrual and day count conventions, fees and carry with hurdles and catch-up provisions, withholding that differs by holder jurisdiction, capital accounts, valuation and reporting. Distributions can be paid on-chain once amounts are determined off-chain.

Workouts stay off-chain too. A contract encoding automatic consequences for a payment default will eventually produce an outcome the manager would not have chosen, at the worst moment.

Two obligations follow. Contract state and the administrator's register must reconcile on a schedule, with a named owner for differences. And subscription and redemption cash needs the controls the fund already applies to cash movements, fiat or stablecoin.

What must never reach the ledger?

Loan agreements, borrower financials, and covenant certificates are confidential, usually under obligations owed to the borrower, and investor personal data belongs in systems you control. Hashing is not an escape where the document is predictable or where a stable hash creates a linkage.

One issue is specific to credit: if the fund holds positions in issuers with publicly traded securities, detailed portfolio disclosure can put holders in possession of material non-public information and restrict their own trading. A wider holder base makes that harder to control.

Keys, roles and what you own at the end

Minting, freezing, forced transfer, recovery, and upgrades each need a named holder, a constraint such as a multisig with a timelock, and a written trigger. Review scope covers the registries, compliance modules, role assignments, and upgrade path, not just the token contract, and repeats after every change to deployed logic.

If a vendor builds it, settle who holds agent roles, upgrade authority, repositories, and intellectual property after handover. Under a build-to-own arrangement, those are yours, and a vehicle with a ten-year life is an odd thing to make dependent on one vendor's survival.

When not to do this
An evergreen or interval structure with periodic repurchase offers already provides scheduled liquidity, using mechanics investors and regulators understand, with no key custody obligation.
Much of the cost tokenization targets is manual reconciliation and reporting, which a capable administrator with modern systems addresses at lower risk.
LP interests already trade through intermediated secondaries with negotiated pricing, and a token does not remove the consent step.
If the investor base is a handful of institutions who neither expect nor want transferability, tokenizing adds cost and risk for a benefit nobody requested.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps, and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories, and intellectual property; engagements are scoped honestly, including the cases where a conventional structure is the better answer; and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/tokenized-private-credit-a-guide-for-institutions

Connect with RWaltz:

ERC-3643 Explained: The Standard for Compliant Tokenization

RWaltz Software — Fri, 04 Sep 2026 11:17:34 +0000

It is not really a token standard

The most useful way to think about ERC-3643 is that it is an identity and permissioning system that exposes an ERC-20 interface at the front. The token contract is the smallest and least interesting part of the deployment. Everything that determines whether the system works sits behind it: an identity registry, investor identity contracts holding signed claims, a registry of which claim issuers are trusted, a registry of which claims are required, and a set of compliance modules encoding the rules of the specific offering.

That reframing has a practical consequence. Teams scope this as a smart contract project, then spend a year running an identity operation. The failure modes that show up in production are almost never bugs in transfer logic. They are expired claims, a trusted issuer that rotated a signing key, a compliance module configured against the wrong threshold, and an investor portal that reports a reverted transaction as an unexplained error.

What the ERC-20 interface does and does not promise

Presenting an ERC-20 interface means wallets can display balances and users can initiate transfers with familiar tooling. It does not mean the token behaves like ERC-20.

A transfer executes only if both parties are verified in the identity registry, with valid unexpired claims from trusted issuers for every required claim topic, and only if the compliance modules permit that particular movement given both parties and the amount. Otherwise, the transaction reverts. That is the correct behavior and the entire point of the standard, and it creates an integration requirement that gets underestimated: every surface that submits a transaction needs to catch the revert, work out which check failed and tell the user something actionable. "Transaction failed" is a support ticket.

The composability claim needs the same scrutiny. A lending market, an automated market maker or a vault is a contract, and a contract has no identity, no claims and no country code. Unless it has been onboarded and whitelisted, transfers into it revert, so most permissionless protocols will never hold these tokens. Treat any roadmap assuming open composability as unvalidated until someone has confirmed the specific integration path.

The failure modes are operational

Budget for these before launch, because each one silently disables transfers for a subset of holders:

Claim expiry. Claims have lifetimes. Nobody tells the holder when theirs lapses; they simply discover they cannot transfer. You need a renewal process and monitoring that flags upcoming expiries.
Trusted issuer changes. If a claim issuer's signing key is compromised, or the relationship ends, the trusted issuers registry has to be updated quickly and existing claims may need reissuing. Write and rehearse that procedure before you need it.
Compliance module arithmetic. Holder count caps, maximum balance per investor and jurisdiction limits are stateful. A module that miscounts, or that was configured against a threshold from an earlier draft of the offering documents, produces either unlawful transfers or blocked legitimate ones.
Frozen and partially frozen balances. These interact with transfer logic in ways that need explicit test coverage, and with investor reporting in ways that need explicit product design.
Gas. Every transfer performs verification and compliance calls, so transfers cost more than a plain ERC-20. Treat that as a network selection input.
The trust model, stated plainly

The standard grants agent roles substantial authority: minting, burning, freezing an address or part of a balance, forced transfer, recovery of a holding to a replacement wallet linked to the same identity, and pausing.

These exist because regulated instruments require them. Courts order transfers, investors lose wallets and expect their positions restored, and a sanctions match requires an immediate freeze. A token without these capabilities cannot serve a regulated offering.

The honest consequence: an ERC-3643 token is not censorship-resistant and not trustless. Holders are trusting the agent. Anyone evaluating this standard with a mental model of blockchain as an instrument nobody can interfere with is looking at the deliberate opposite. Say so during scoping rather than after issuance.

Which makes constraining those powers a first-order design task, not a hardening step. Each role needs a named holder, a constraint such as a multisig with a timelock for anything structural, and a written trigger and approval path for forced transfer and recovery. Two questions belong in the vendor contract if someone else is building it: who holds agent roles and upgrade authority after handover, and who holds the repositories, deployment scripts, and intellectual property. Under a build-to-own arrangement, the answer to both is you, with another team able to operate the system from documentation and tests. A token recording investor positions in a long-lived asset is an odd thing to make dependent on one vendor's continued existence.

The privacy detail that rarely gets mentioned

Personal data stays off-chain, which is right. What goes on chain still matters. Each holder's wallet links to a persistent identity contract, with a country code in the registry. Even without names, that is a stable, correlatable identifier carrying a jurisdictional attribute, and anyone who can tie one identity contract to a real person can then read that holder's full transaction history for the token. For a private placement with a small holder base, that is a real confidentiality question for counsel and investors.

Review scope is wider than the token file

Because this is a set of interacting contracts with privileged roles, an audit limited to the token contract covers the least risky component. Scope should include the registries and who may modify them, every compliance module and their interactions, agent role assignment and constraints, the recovery and forced transfer paths, and the upgrade mechanism where the contracts are upgradeable.

Two things to verify with any vendor. If the implementation is a fork of the reference version rather than the reference version itself, the review must cover the fork and the audit report must match the exact version being deployed. And review is a cycle: compliance rules change, modules change with them, and every change to deployed logic needs review again.

When a lighter option is the right call

ERC-3643 earns its complexity when eligibility rules are non-trivial, transfers should clear programmatically rather than by manual approval, and the same verified investor base will serve multiple offerings. Outside that, simpler is usually better:

If every transfer requires human sign-off under the governing documents anyway, automated enforcement is automating a gate you already staff. A plain ERC-20 with an off-chain transfer agent is cheaper and has less to go wrong.
If the rule set is small and stable, a lighter restricted transfer approach such as ERC-1404 covers it with a fraction of the surface area.
If the position needs tranches with different lockups or rights, partitioned balances in the ERC-1400 family may model it more naturally.
If the investor base is a dozen participants, a register maintained by a competent administrator carries no key custody obligation and no contract attack surface at all.

That last option is the baseline any tokenized design should be measured against, and it wins more often than the market admits.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps, and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories, and intellectual property; engagements are scoped honestly, including the cases where a simpler standard or no token is the better answer; and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/erc-3643-explained-the-standard-for-compliant-tokenization

Connect with RWaltz: