They should compare one-off integration handling with repeatable distribution design. A project model optimises for individual relationships, while a product model standardises trust, access and onboarding so each new consumer adds less friction than the last.
Choosing the right operating model for an API
The comparison should start with whether the API is being treated as bespoke delivery for a single relationship or as a repeatable capability that can scale across consumers. That distinction changes the design priorities: a project approach solves the immediate integration, while a product approach creates a stable service with clear expectations for access, onboarding, versioning and support.
In corporate banking, that choice is not just organisational. It affects whether the API can be reused safely across channels, counterparties and internal teams without reworking trust decisions every time a new consumer appears.
What changes when you treat the API as a product
A product model asks whether the interface can be discovered, requested, approved and consumed with predictable rules. That usually means standard contracts, published lifecycle expectations, version discipline and a design that assumes multiple consumers with different technical maturity and control needs.
A project model, by contrast, is usually optimised for a named client or programme milestone. It can be faster to start, but it often leaves the bank carrying hidden integration debt because each new use case requires fresh negotiation around permissions, data fields, testing, and operational support.
For banking teams, the practical test is whether the API lowers friction over time. If each additional consumer still needs a one-off design discussion, the interface is behaving like a project deliverable. If each new consumer can join through an already-defined pathway, the API is behaving more like a product.
Trust, access and onboarding as the deciding factors
The strongest comparison is not feature count, it is whether trust and access are standardised. A product-oriented API usually has a repeatable onboarding path, clear entitlement rules, bounded data exposure, and consistent monitoring expectations so that access decisions do not have to be reinvented for every relationship.
That is where banking teams should be strict about external-facing controls. Published access criteria and stable consumption rules reduce ambiguity for relationship managers, developers and control teams, and they make it easier to spot when a custom arrangement is drifting into exception handling. Guidance from OWASP API Security Top 10 is useful here because it frames the API as a governed surface, not just an integration endpoint.
When the service needs repeated approvals, narrow per-client exceptions or manual onboarding workarounds, the bank is still behaving in project mode even if the interface is technically exposed as an API. A product model is the point at which the bank can describe, defend and operate the API without re-litigating the basic trust model each time.
Risk and Threat Considerations
API decisions become risky when project-by-project exceptions are left in place after the first launch. Custom onboarding, ad hoc entitlements and inconsistent access rules create a wider attack surface, because the bank may no longer know which consumers have which privileges or which integrations still depend on legacy approvals.
Failure mechanism: Project handling encourages one-off trust decisions, duplicate credentials, inconsistent authorisation and weak lifecycle discipline, which makes misuse harder to detect and harder to revoke cleanly.
Impact: The result can be excessive access, broken revocation, operational fragility and avoidable exposure if a consumer, partner or integration path is compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | API onboarding and trust standardisation depend on reliable authentication to the API. |
| API5 — Broken Function Level Authorization | Project-style exceptions often create inconsistent function permissions between consumers. | |
| API9 — Improper Inventory Management | Product operating models need clear inventory of consumers, versions and exposed interfaces. | |
| Recommendation — Enforce strong API authentication and rotate credentials through a repeatable onboarding process. Apply function-level authorization checks consistently across every API consumer. Maintain an authoritative API inventory and retire unmanaged endpoints promptly. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Repeatable onboarding and offboarding are central to turning API access into a product process. |
| IA-5 — Authenticator Management | Stable API access depends on controlled issuance, rotation and revocation of credentials. | |
| Recommendation — Standardize API consumer account lifecycle and revoke access through defined procedures. Manage API credentials centrally and enforce rotation, expiration and revocation controls. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question turns on consistent access design across repeatable API consumption. |
| Recommendation — Define and enforce a uniform access control policy for API consumers. | ||
Practitioner Guidance
What to verify: Check whether the API has a standard intake path, a repeatable entitlement model and a documented offboarding or revocation process. If those three controls are missing, the API is not yet operating as a product, even if it is used repeatedly.
Decision rule: If the next consumer requires materially new access logic, new onboarding steps or a bespoke support arrangement, treat that as project state. If the same controls can be reused with only parameter changes, the API is closer to a product and should be governed that way.
Practitioner takeaway: The best test is whether the API becomes easier to consume and safer to govern with each new user. If scale increases friction instead of reducing it, the bank is still carrying a project mindset.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- What should security leaders look for when deciding whether API security ownership belongs with platform teams or the security organisation?
- What should identity teams compare when deciding whether a shared access model is working?
- How should security teams prioritise NHI remediation in cloud environments?