A senior technology leader who has spent more than a decade architecting compliant platforms at Visa, SAP, and McAfee spent two weeks reviewing 72-hour mental health prototypes — and found that the operational disciplines that protect financial transactions translate, almost line for line, into the disciplines that mental health software needs but rarely has.
In financial services, trust is not a static property a system either has or does not have. It is a continuously revised estimate, recalculated on every transaction, drawing on signals the user is barely aware of: location consistency, device fingerprint, transaction velocity, behavioral pattern alignment, time-of-day priors, spending tier history, and merchant risk class. Every Visa transaction in the world is the output of a trust calculation that completes in under a second, and the result of that calculation is not “approved” or “declined.” It is a probability distribution, weighted against business risk thresholds, over what kind of transaction this might be.
Madhushree Kumari has spent more than a decade building the platforms that perform this kind of work. As a Senior Technology Leader at Visa Inc., with prior tenure at SAP and McAfee, she has led the design of scalable, compliant architectures serving global financial markets — systems where the operational discipline of continuous trust scoring is so deeply ingrained that it functions as the engineering culture rather than a feature. When Hackathon Raptors invited her to evaluate submissions to MINDCODE 2026 — an international 72-hour hackathon challenging participants to build software for human health — she encountered a category of product where continuous trust scoring would have been more useful than any of the other engineering disciplines on display, and where almost no team had thought about it.
“In payments, you do not get to assume the user is who they say they are because the user said so,” Kumari observes. “You assume the user might be impersonated, the device might be compromised, the network might be hostile, the merchant might be running a fraud ring, and the transaction might be a coerced purchase. You build the architecture around that assumption. Mental health software is starting to need a version of that mindset, but very few products are built that way.”
Why Mental Health Software Needs a Trust Score
The submissions Kumari reviewed at MINDCODE spanned a familiar range: passive burnout detection systems, AI-coached wellness platforms, mood and journal tracking apps, mental health companions with safety guardrails, and gamified emotional wellness tools. The technical sophistication varied. The thinking about user identity and trust did not vary so much as it was almost entirely absent. Most submissions, by default, accepted that the person typing into the app was the person whose mental health record the app was building. Most submissions had no plan for what to do if that assumption became false.
For Kumari, this is the gap that financial-services architecture closes by default and consumer mental health software does not close at all. “Identity in payments is a continuously verified assumption,” she explains. “If the user normally logs in from Mumbai and suddenly logs in from a different country at 3 a.m. on a transaction outside their normal pattern, the system flags it. Not blocks it — flags it for additional verification. The trust score drops. The user might be asked to do step-up authentication. The transaction might be held. The risk of harm is reduced not by being right about the user, but by being honest about the uncertainty.”
The corresponding pattern in mental health software, she suggests, is something almost no team in her batch had built: a continuous evaluation of whether the person currently using the product is the person whose mental health record the product holds. Is it the user? Is it a controlling partner who has access to the device? Is it an employer who has gained access to a corporate account? Is it a parent in a custody dispute? Is it the user, but at a moment of acute crisis where the system should respond differently than it would respond to the user during a typical week? Each of those is a distinct trust state with different appropriate responses, and the architecture that recognizes them is more or less the architecture that fraud detection has been refining for decades.
“You cannot fix that gap with a stronger password,” she observes. “You fix it by recognizing that identity in mental health software is not a one-time login event. It is a continuously revised estimate of who is on the other side of the connection and what kind of session this is.”
The Symmetry Between Fraud and Crisis
A particular pattern that Kumari emphasized in her reviews was the structural similarity between fraud detection and crisis detection. Both are problems of recognizing, in real time, that the user’s current behavior diverges from their normal pattern in ways that indicate the user (or the system) is now in a state the system was not designed to handle. In payments, the divergence might mean a stolen card. In mental health software, the divergence might mean a suicidal episode, a manic state, a coerced session, or an account compromise.
The engineering disciplines that recognize and respond to these divergences are nearly identical. They both depend on baseline modeling — knowing what normal looks like for this specific user. They both depend on multivariate signals — combining time-of-day, device, network, behavior, and content into a composite risk estimate. They both depend on graduated responses — not binary block-or-allow, but a tiered response menu that escalates appropriately. They both depend on explainability — when a high-risk event triggers a system response, the operators need to know why. And they both depend on appeal mechanisms — when the system gets it wrong, the user needs a path to correction that does not require breaching the privacy of the original determination.
“Fraud detection is the most operationally mature continuous-trust discipline that exists,” Kumari notes. “It has been refined under adversarial pressure for decades, against well-resourced opponents, with regulatory accountability and quantifiable feedback loops. Mental health software has none of those advantages — no shared adversary database, no regulator forcing maturity, no immediate quantifiable feedback. Borrowing the operational patterns from fraud detection is not metaphor. It is the most pragmatic available source of architectural patterns for a domain that needs them.”
Her recommendation to teams in this space was specific: build the continuous trust scoring layer before you build the personalization layer. Personalization on top of an unverified identity is the hazard the entire MINDCODE submission set was, in different ways, trying to solve. Personalization on top of a continuously verified identity is a feature.
Compliance as an Architecture, Not an Audit
A second pattern that Kumari flagged across her reviews was how teams discussed compliance. Several submissions cited HIPAA or GDPR awareness, AES-256-GCM encryption, or WCAG-compliant interfaces as if these were complete answers to the question of whether the system was responsibly built. For someone whose career has been spent inside regulated platforms, this framing reads as a category error.
“Compliance is not a checklist of things the audit will look for,” she explains. “It is an architectural posture. It shapes every decision about how data is stored, who can access it, how access is logged, how long records are retained, where the data physically lives, what happens when it crosses a border, and how the user exercises their rights. You do not bolt that on at the end. You build the entire system around it from the first commit, or you do not get it at all.”
The teams in her batch that scored highest treated compliance as an architectural principle that constrained their design choices in productive ways. They had thought about data residency. They had considered who could see the audit logs. They had considered how the user would request deletion and what it actually meant in their system. The teams that scored lower had cited compliance frameworks without internalizing them — they had encryption, but not key management; they had consent flows, but not consent revocation; they had audit logs, but no clear policy for who could read them or when.
“The hardest part of building compliant systems,” Kumari observes, “is that the work is invisible when you do it right. The user does not see the data residency decision. The user does not see the access control policy. The user does not see the audit log retention rule. They see a product that works. The reason regulated platforms employ engineers like me is that someone has to make sure the invisible work is done correctly, because the consequences of not doing it correctly are also invisible — until they are not.”
Operational Maturity as the Multiplier
A theme that ran through Kumari’s evaluations was what she called operational maturity: the discipline of preparing a system for the conditions it will actually encounter in production rather than the conditions it encountered in the demo. This is not a single feature. It is a posture toward engineering in which the team continuously asks what could go wrong, designs for the failure mode, and instruments the system so that when something does go wrong, the team will know.
“In payments, you assume things will fail,” she observes. “Networks will partition. Databases will have replication lag. A merchant will go offline mid-transaction. A regulator will require a feature you did not anticipate. The system has to keep running through all of it, and the user should not see the failure if you can help it. You do not build that posture by adding it to a sprint at the end. You build it by treating every architectural decision as a small bet on what will be true in production.”
Her advice for hackathon teams aspiring to operate in regulated spaces was concrete: instrument before you optimize. Add structured logging with correlation IDs from the first endpoint. Add rate limiting and circuit breakers before you add features that depend on them not failing. Define what “down” means for your product and what the user should see when it happens. Write a one-page operational runbook for the most likely failures. None of these things are exotic. All of them are skipped routinely by teams who think of them as enterprise concerns. None of them, in her experience, are enterprise concerns — they are the difference between a product that helps users and a product that fails them quietly.
“Operational maturity is the multiplier on every other engineering decision you make,” Kumari reflects. “A brilliant ML model that crashes under real load helps no one. A well-designed UX that loses session state during a network blip helps no one. A privacy architecture that has no audit log helps no one. The discipline of preparing for production conditions is what turns a good idea into a deployable system, and very few hackathon teams are taught to think that way.”
What the Strongest Submissions Had in Common
The submissions that scored highest in Kumari’s batch shared a quality that her financial-services background made impossible to ignore. They did not just build features; they thought about what would happen when the features met real users at scale, under adversarial conditions, with regulatory scrutiny. They had designed identity systems that could survive an account compromise. They had designed logging systems that could survive a regulator’s request. They had designed consent flows that could survive a user’s change of mind. They had designed AI integrations that could survive an inference provider’s policy change.
“The teams that did this,” she observes, “were not necessarily the most technically ambitious. They were the teams that had spent some part of their 72 hours imagining the system in production. That is the discipline that turns a hackathon submission into a product anyone can use responsibly. It is also, not coincidentally, the discipline that the financial-services industry has been forced to develop because the cost of failure is high enough that everyone has to take it seriously. Mental health software is starting to face the same kind of stakes. The architecture has to start meeting those stakes.”
The closing observation in her review notes was less an assessment than a hope: that the engineers who build the next generation of mental health software learn from the operational disciplines that other regulated industries have already paid the cost of developing. The patterns are mature. The frameworks exist. The hard part is the willingness to apply them in a domain that is still being built largely by teams who have not yet been told that the standards are different here.
MINDCODE 2026 — Software for Human Health was an international 72-hour hackathon organized by Hackathon Raptors from February 27 to March 2, 2026, with the official evaluation period running March 3–14. The competition attracted over 200 registrants and received 21 valid submissions in the mental health and wellness domain. Submissions were independently reviewed by a panel of judges across three evaluation batches. Projects were assessed against five weighted criteria: Impact & Vision (35%), Execution (25%), Innovation (20%), User Experience (15%), and Presentation (5%). Hackathon Raptors is a United Kingdom Community Interest Company (CIC No. 15557917) that curates technically rigorous international hackathons and engineering initiatives focused on meaningful innovation in software systems.