Consider a mid-sized factoring company based in Ankara, with 312 employees offering cheque discounting and invoice financing to corporate clients. Its accounting system is tied to a legacy domestic ERP, and payment approvals run through a separate extranet connection maintained by a single bank. When a new insurance partner proposes an integration to bundle credit protection with the factoring product, the internal estimate lands at eight months of development. By the time the project is scoped, the opportunity has moved to a competitor. The bottleneck is not budget — it is an architecture that was never designed to be opened. This is precisely where API logic becomes relevant. But treating it as a technical detail is a reliable way to miss the point entirely.The central argument of this article is this: in fintech, an API is not a connectivity tool — it is a strategic architectural decision that determines whether financial services can be decomposed along customer value flows rather than internal departmental boundaries. Companies that get this wrong publish APIs but nothing changes; integration still takes eight months, just with different technology underneath. The granularity of the service decomposition — which operations are exposed as independent callable units — is a business design question before it is a technical one, and it should be answered by someone who understands the revenue model, not only the codebase.Service-oriented architecture (SOA) has been part of the conversation in Turkish financial services since the mid-2000s. Large banks invested in enterprise application integration layers, launched ESB (Enterprise Service Bus) programmes, and built internal middleware to connect core banking with ancillary systems. The critical distinction between that generation of work and an API strategy is the direction of exposure. SOA was predominantly inward-facing: it connected internal systems with greater reliability and reduced point-to-point coupling. An API, by contrast, is an outward-facing publication decision. A financial institution that publishes an API is making an explicit statement: ‘you may trigger this operation from inside your own product.’ That is a business model decision, not an infrastructure one, and it carries consequences for customer ownership, pricing power, and partnership design that go well beyond the technical team.A concrete illustration: an instalment financing company embedded within a retail chain in Istanbul. At the point of sale, each credit approval requires the sales associate to switch to a separate screen, manually run identity verification, and check credit limits — an average transaction adds roughly four minutes to the checkout process. With a properly designed API layer, the same identity check, limit query, and approval response can be embedded directly into the retailer’s point-of-sale software as a single web service call. The checkout flow never breaks. This is the efficiency case for API integration, and it is straightforward. But something more significant is also happening: the financing company no longer controls the customer touchpoint — the retailer does. Companies that decompose their services without thinking through this transfer of interface ownership find themselves technically integrated but strategically marginalised. In comparable arrangements across Turkish consumer finance, this is precisely where the difficult conversations start.Turkey’s rollout of e-Invoice (e-Fatura) and e-Ledger (e-Defter) obligations in 2012 created an unexpected foundation for programmatic financial workflows. Large taxpayers now produce and transmit invoice data in structured XML format as a regulatory requirement. When invoice data flows machine-to-machine as a baseline, payment triggering and reconciliation processes become candidates for automation in a way that was not structurally possible before. Think of a textile exporter in Gaziantep with 378 employees managing foreign currency transfers across four separate banks. Each bank has its own internet banking interface, its own CSV export format, its own approval workflow. The finance team spends a meaningful portion of each working day copying payment instructions from the ERP into individual bank portals. Had each bank published a standardised payment initiation API, the entire process could be triggered from the ERP with a single instruction set. This is an open gap in Turkish corporate banking as of early 2013 — and it will not remain open for long.A necessary counterargument: API architecture does not generate meaningful value in every fintech context. Small-scale providers operating through a single channel with limited integration requirements face a genuinely long payback horizon on API investment. More importantly, API projects launched without a defined integration use case tend to produce technical debt rather than business value — a service catalogue that grows but goes uncalled. The sequence matters: identify which operations, if externally callable, would unlock a new revenue stream or partnership model; then design the service boundary around that transaction logic. Reversing the sequence — publishing APIs first and hoping partners emerge — is a pattern that has produced expensive lessons for several early adopters in the domestic banking sector.Back to the Ankara factoring company. The eight-month integration estimate is a symptom of services designed around internal process steps rather than atomic, independently meaningful operations. If credit limit enquiry, identity verification, and approval issuance were each published as discrete callable services, onboarding a new insurance partner becomes a six-week project. That difference is not driven by a technology choice — it is driven by how the system was structured from the beginning. The question fintech strategists in Turkey should be asking in 2013 is not ‘should we build APIs’ but rather ‘are our financial services decomposed into units that can be embedded inside someone else’s product?’ Institutions that ask this question early enough to act on it will find that ecosystem partnership speed becomes a competitive asset that is genuinely difficult for late movers to close.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 24, 2013. The English edition has been reviewed and edited by the author.