Melio, recently acquired by Xero, processes billions of dollars in B2B payments for over 100,000 small and medium-sized businesses in the United States. The company has raised $654 million, landed on the Forbes FinTech 50 and Cloud 100, and built a 683-person team with over 200 engineers.

Every payment that Melio bears directly carries risk such as fraud, compliance violations, and non-sufficient funds. If the risk system is slow, payments are slow or go unsent. If the risk system is wrong, Melio loses money.

For years, the team that owned risk infrastructure also owned a homegrown Python feature store. It worked on a small scale — until it didn't.

Our business is not building a feature store. Our business is fintech. Feature stores are a hard engineering problem.

Shimon Klebanov Engineering Manager, Data & AI Infrastructure

The decision became simple: keep pouring engineering into infrastructure, or hand that problem to Chalk and put those hours toward the models that decide whether bills get paid. They made the switch.

The original feature store was straightforward: a ty service that computed and served features for the risk team's models. For a startup processing a modest volume of payments, it performed as expected.

As Melio's payment volume grew, its needs quickly outpaced what a basic feature store could support.

Scaling-related upkeep absorbed most of the engineering team’s bandwidth. There was no versioning, so there was no way to track changes, rollback a bad deploy, or audit what was served when. Feature discovery, dependency tracking, lineage: none of it existed. And the engineers maintaining it were the same engineers who should have been building fraud models.

The bottleneck was felt most by the people closest to the models. Data scientists on the risk team – the ones who actually understood what features mattered – were locked out. Only a handful of engineers who knew the system's internals could ship anything.

On top of this, the risk team's requirements were demanding. Melio's compliance models require a high degree of accuracy to meet strict regulatory SLOs. Fraud models operate on probability and require a different kind of tolerance. Both had to coexist on the same infrastructure.

Melio's Risk Platform team had seen this movie before:

I worked at two companies where they tried to build a feature store internally. It was basically a very bad product that was never even used. When I came here and worked with Chalk, it felt really easy. At my previous companies, those internal products always failed.

Mush Kabalo Engineering Manager, Risk Platform

Chalk replaced Melio’s in-house feature store entirely. Scaling, versioning, metadata management, caching, the offline store: all of it became possible when Melio moved to Chalk. The engineers who maintained the old system could finally focus on what actually attracted them to join Melio: building fraud and compliance models.

Chalk absorbed the work that had been eating the team's time and gave Melio control over how risk assessments hit their databases. The team opted to run Chalk against DB replicas on a cluster sized for both application and Chalk traffic — protecting production while keeping state accurate.

You don't want someone getting blocked when they're trying to log into the application because risk is running an assessment on 100,000 payments. Chalk enables us to separate these data streams.

Shimon Klebanov Engineering Manager, Data & AI Infrastructure

Chalk connected to all of Melio's data sources: MySQL, Postgres, Snowflake, and native enrichment APIs. This isn't a nice-to-have integration. Chalk powers risk assessment on every payment that moves through Melio. Fraud detection, compliance checks, non-sufficient funds evaluation: all on the same platform.

We don't have an alternative to Chalk. If Chalk goes down, we delay payments, and delaying payments means losing money.

Shachar Helmer Software Engineer

Before Chalk, feature development lived with a small group of engineers. After Chalk, roughly 20 developers across the risk organization write and deploy features, including data scientists, without needing engineering permissions.

That last part matters. Melio's data scientists know what features the models need. With Chalk, they can more easily shape new and existing models.

Teams now add enrichments, modify features, and deploy changes without routing through the infrastructure team.

Then something unplanned happened. Melio's data analysts started using Chalk to enrich product analytics events flowing through Kinesis into Snowflake, Tableau, FullStory, and Amplitude.

Now application teams outside risk are asking the same question: should we query the database directly and write pipeline code around it, or just write features on Chalk? That conversation didn't exist a year ago.

Chalk sits between the risk decision models and Melio's data. When a payment is initiated, the risk platform queries Chalk for features, passes them to the model, and returns a decision.

• Inbound data sources: MySQL, Postgres, MongoDB, Snowflake, external enrichment APIs
• Primary flow: Application triggers risk assessment → Risk platform queries Chalk → Chalk computes and serves features → Models return decision
• Secondary flow: Kinesis events enriched through Chalk for product analytics → Output to Snowflake, Tableau, FullStory, Amplitude

Chalk owns the feature layer. The risk platform orchestrates, querying Chalk for structured feature inputs and feeding them to models and, increasingly, to risk agents that assist with manual review and automated rule-based decisioning.

Replacing Melio’s feature store changed how the team works day to day. Before Chalk, Melio's in-house feature store needed dedicated engineering maintenance and limited contributions to a small group of engineers. Onboarding was internals-heavy, risk queries hit operational databases, and the platform served risk assessment only.

With Chalk, the feature store is fully managed with zero internal headcount. 20+ developers and data scientists across the risk org now ship features independently, risk workloads run separately from production, and use cases have grown beyond risk into product analytics — with more application teams asking to get on.

Three years ago, Chalk replaced a broken feature store. Today it supports the system that decides whether payments clear, the layer that feeds product analytics, and the platform that non-technical teams are starting to build on.

Chalk isn't something complementary to our business. It's something that's critical to our business.

Shimon Klebanov Engineering Manager, Data & AI Infrastructure

Melio’s next priorities are practical. More teams want in. Data quality monitoring matters now that 20+ people are writing features instead of four. And the risk agents that already consume Chalk features for manual review and automated decisioning are only going to get more sophisticated. Chalk is the infrastructure underneath all of it.