Native Finance Function

When you order from an online shop, you can often pay in installments right there. You’re not redirected to a bank and don’t fill out a separate form. Installment payment has become part of the ordering process. That’s exactly what the term Native Finance Function means: a money function that’s firmly built into a product that was actually designed for something else. “Native” here means roughly “included from the start,” not bolted on afterward. In the background, a financial service provider still does the work, actually processing the payment and bearing the legal responsibility. The user usually sees none of this.

Why platforms suddenly do banking business

For companies, the incentive is very direct: money. Every payment, every loan, and every insurance policy carries a fee. Whoever brings this function into their own app gets a share of it. For many platforms, this has become a more important revenue source than their original business. A delivery service sometimes earns more from processing the payment than from the pizza itself.

The second reason is drop-off. Every additional step in the payment process costs customers. Anyone redirected to a foreign site, who forgets a password and gives up, doesn’t buy anything. Built-in finance functions reduce this friction. That’s why companies measure very precisely how many people complete a purchase when the payment stays within the product.

For traditional banks, this is an uncomfortable development. They don’t necessarily lose the business, but they lose contact with the customer. The brand that stands out is the platform, not the bank behind it. In industry jargon, this is called: the bank becomes a mere infrastructure provider.

What happens between the app and the bank

Technically, behind every such function is an interface, or API for short. This is a defined way for two programs to communicate with each other. The app sends a request, for example: this customer wants to pay 89 euros in three installments. The financial partner checks it and responds with yes or no. The app shows the user only the result, in its own design and language.

The check itself often runs automatically and within fractions of a second. Models assess how likely it is that someone will repay. They use information from the application, data from purchasing behavior, and information from credit agencies. This is exactly where things get tricky, because such models can systematically disadvantage certain groups. That’s why lawmakers require that people be able to contest an automatic rejection.

It’s important to distinguish this from classic cooperation. In the past, a shop would simply link to a credit provider. Today, the function is deeply embedded in the process, often without a visible switch. However, the permission for financial transactions, the license, still belongs only to the partner in the background. The platform is not allowed to grant loans without this partner.

Installment purchase, driver account, merchant credit

The best known example is “Buy Now, Pay Later.” Providers like Klarna have brought this function to thousands of shops. Insurance policies offered directly during ticket purchase work in a similar way. Ride-hailing services, too, often pay out earnings to their drivers via their own account within the app.

In business news, the term usually appears in the context of “Embedded Finance,” the umbrella term for embedded financial services. When a software company announces that it now offers loans to its merchants, this model is almost always behind it. Regulators are now looking more closely, especially at installment purchases by young customers. The most common misconception is the assumption that the app itself is the bank – which, as a rule, it is not.