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 an international team with over 200 engineers.

Every payment that Melio processes carries risk such as fraud, compliance violations, and non-sufficient funds. If the risk system is slow, this impacts payment processing speed. If the risk system is wrong, Melio could lose 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.

The decision became simple: keep pouring engineering into infrastructure, or hand that problem to Chalk and put those hours toward the models where mistakes carry real consequences. They made the switch.

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

Scaling-related upkeep absorbed most of the engineering team’s bandwidth.

The bottleneck was felt most by the people closest to the models. Data scientists on the risk team 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.

Mush Kabalo, who runs Melio's Risk Platform team, had seen this movie before:

"I worked at two companies that tried building a feature store internally. Getting results was always an uphill battle. When I came to Melio and worked with Chalk, it felt really easy."

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.

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.

"If Chalk goes down, it could delay payments. It has become a key infrastructure component of Melio."

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.

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: databases, data warehouses, and external 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 from the team.

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.

"The stability of Chalk has improved vastly for us. And given that our scale also grew, that means double the improvement."

Shachar Helmer Software Engineer

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.