If you run product or engineering at a licensed fintech or platform, you've probably scoped the in-house build at least once. The estimate usually lands around 12 to 18 months of focused engineering, plus a compliance hire or two who understand the relevant EU and MENA obligations, plus ongoing maintenance as providers deprecate APIs, regulations move, and the sub-processor chain needs quarterly attention. The work isn't one feature. It's a control plane: accounts, money movement, settlement, reconciliation, policy and audit, sitting between your product and the authorised providers that actually execute.

The second option is to assemble specialists. A smart-contract wallet provider for accounts, a ramp aggregator for money movement, a Travel Rule provider and an AML screening vendor for compliance, an EMI rails partner for settlement, and the session-key and routing logic you write yourself. That's several contracts, several integration cycles, several sub-processor paperwork loops, several relationships to keep current, and several places where someone else's API change can break your product. You've also inherited the cross-vendor liability of stitching them together.

The third option is to integrate one control plane: one SDK, one contract, one integration engineer on our side, and the orchestration between providers already built. This is a walkthrough of how that holds up architecturally, the trade-offs we accepted, and what an integration actually involves. The headline number people ask for is the timeline, so I'll start by being precise about it: rollout depends on your scope, your regulatory responsibilities and how far along your provider onboarding is. Weeks rather than quarters is the realistic frame, not a fixed promise. The rest of this piece is about why the architecture earns that.

Non-custodial by default: the proven first rail

OVAAL is a neutral control plane. Accounts, money movement, settlement, reconciliation and policy live in one layer, and providers and rails plug in beneath it. The first rail we proved under that layer is account-abstraction wallets, and it's the cleanest illustration of why the architecture shortens integration time. Crypto is the rail here, not the category. The same orchestration sits above fiat and EMI rails too.

On that rail, end-user funds never enter OVAAL's custody. The end-user holds a smart-contract wallet (ERC-4337 account abstraction) with signing authority bound to a passkey or MPC share. Instructions are initiated by the end-user, directly or through policy-scoped automation. The assets stay on-chain throughout. OVAAL orchestrates, sponsors gas through paymaster keys where needed, and writes audit-log events, but never holds the funds. Where custody does apply on other rails, it sits with the partner or an authorised provider, not with us.

Why this matters for integration time:

  • No custody integration work on this rail. If OVAAL held the funds, every partner would have to work through a partner-to-custodian relationship: KYC, KYB, account opening, segregated asset accounts, reconciliation pipelines, audit hooks. That's weeks of compliance and engineering per partner. The non-custodial path skips it.
  • Cleaner liability posture. Compliance review moves faster when the answer to "who holds the funds" is "the end-user, on-chain." There's no fiduciary layer to validate and no contingent custody agreement to negotiate.
  • No licensed-trust dependency. Custodial infrastructure means either being a licensed custodian or wiring into one. Both add months. The non-custodial default avoids that path for this rail.

The trade-off is honest: end-user key security moves to the end-user experience. We soften it with account-abstraction recovery (passkey plus social plus MPC), which is safer than a seed phrase for most people. It still isn't the liability profile of a custodian holding funds, and a partner that specifically needs a licensed custodial model should pair one with us rather than treat us as one. We say so on the first call.

One SDK, designed as a single surface

Most specialist-vendor integrations take weeks because each vendor's SDK is a separate surface: different auth patterns, different webhook signatures, different error semantics, different sandbox setups, different pagination rules. Your eng team has to learn five shapes.

OVAAL's SDK is designed as one surface:

  • One auth pattern. API key plus HMAC signatures for webhooks. Uniform across accounts, money movement, settlement, policy and compliance. You write the auth code once and it handles every module.
  • One webhook event schema. Every event type follows the same envelope: event_type, event_id, timestamp, partner_id, partner_user_id, payload, signature. You write one webhook receiver and one idempotency handler.
  • One sandbox, one staging, one production. Three environments, not fifteen. Each environment uses the same API keys rotated per environment.
  • One pagination pattern. Cursor-based, uniform across all list endpoints.
  • One error taxonomy. Every error has a stable error code plus human-readable message plus retry hint. Your error-handling code is one switch statement, not five different error-handling dialects.

The practical consequence: when your engineers open the documentation for the first time, they learn one surface, not five. A competent engineer can navigate every capability we ship after a focused read rather than a week of context-switching between vendor dialects. We haven't published integration-time benchmarks yet because we won't quote numbers we can't stand behind. Honest case retros are a post-launch deliverable, and they'll carry the real orientation and time-to-production figures once partners are live.

Versioning as a first-class design decision

Specialist vendors often ship breaking API changes with a "deprecated" notice and 6 months to migrate. If you're integrating 4 vendors with 6-month migration windows staggered, you're doing breaking-change migration work continuously.

OVAAL's API versioning:

  • 12-month minimum deprecation notice before any breaking change. During the deprecation window, both old and new versions run in parallel. You migrate on your timeline.
  • Minor changes ship without version bump. New fields are additive. New endpoints exist alongside old.
  • Major version bumps ship as v2 in the URL. Your code chooses when to migrate.
  • Changelog published with every release. Subscribe via RSS. Every partner's engineering lead gets the changelog delivered.

We made this a published policy before V1 launch, which means you can plan around it. Every partner MSA references the versioning policy as part of the commercial terms. If we violate it, it's a contract breach, not a unilateral vendor move.

The compliance stack is an architecture choice, not a feature

In most assembled stacks, compliance is an add-on. You integrate a wallet SDK, you integrate a ramp SDK, and then you bolt a Travel Rule provider on top of both so transactions carry the right data before they settle. That wiring is manual: your code routes the Travel Rule call at the right moment, handles the response, retries on failure, and makes sure the audit log captures the exchange. Every provider you add is another orchestration job you own.

In OVAAL, the compliance checks sit inline in the execution path. When you call ovaal.wallets.transfer(...) or ovaal.payments.execute(...), the checks run as part of the operation: Travel Rule exchange through a Travel Rule provider, AML screening through an AML screening vendor, sanctions matching and risk scoring. Partners configure which integrations apply under their own authorisation. If a check fails, the instruction doesn't execute, and your webhook receives a compliance.transaction.flagged event with the full reasoning.

Your integration code doesn't orchestrate the compliance calls. It specifies the policy (thresholds, risk tolerances, counterparty trust levels) through partner-portal configuration, and the execution path enforces it. The same policy engine is what governs who or what may initiate an action under defined limits and approvals today. Letting software agents initiate financial actions within those guardrails is on the roadmap (Planned / Design Partner), not a live claim. We don't ship autonomy we haven't built.

Why this matters for integration time:

  • You don't write Travel Rule code. It's already there, executing at the right moment in every transfer.
  • You don't write AML screening code. Same.
  • You don't write sanctions-list matching code. Same.
  • You write policy config, not execution code. That's a day of work, not weeks.

The trade-off: you give up the freedom to drop in a compliance vendor we haven't integrated yet. If you need a screening provider outside our current set, we can prioritise that integration with you as co-development, but it isn't a same-day swap.

Reference architecture

+----------------------------+
|  Partner's product UI      |   <- Partner-built, partner-branded
|  (web, mobile, Telegram)   |
+-------------+--------------+
              |
              | OVAAL SDK (TypeScript/JS)
              v
+----------------------------+
|  OVAAL API layer           |   <- Versioned REST + webhooks
|  (wallets / ramps / pay /  |
|   automation / compliance) |
+----+----------+------------+
     |          |
     |          v
     |  +--------------------+
     |  | Compliance exec    |   <- Inline in every transfer
     |  | (Travel Rule + AML |
     |  |  + sanctions)      |
     |  +--------------------+
     |          |
     v          v
+----------------------------+
|  Provider / rail chain     |
|  - stablecoin issuer       |
|  - Travel Rule provider    |
|  - AML screening vendor    |
|  - EMI / SEPA rails partner|
|  - chain RPCs              |
+----------------------------+

Partner holds:                    OVAAL holds:
- User identity (KYC/KYB)         - Nothing custodial
- User brand + UI                 - Orchestration code
- License (CASP/EMI/VARA/CBB)     - Audit logs
- Ledger (source of truth)        - Policy enforcement
- Support
                                  End-user's keys hold:
                                  - Signing authority (passkey/MPC)
                                  - Smart-contract wallet keys

None of OVAAL's boxes hold end-user funds. The architecture is deliberately flat. You own the layer above OVAAL: the UI, the identity, the ledger. The end-user's keys own the layer below: signing and, on this rail, custody. OVAAL is the control plane in the middle that orchestrates between them. Orchestration is the part that takes the better part of two years to build in-house and is what you skip by integrating a layer that already exists, which is where the time saving comes from.

An illustrative integration timeline

The phasing below is a reference shape, not a quote. Where you land depends on scope, your regulatory responsibilities, and how far along your provider onboarding is. Treat the week numbers as the typical order of work, not a contractual schedule.

Kickoff

  • Signed MSA and DPA in hand.
  • Architecture walkthrough call with your eng lead, compliance lead, and BD lead.
  • Sandbox environment provisioned. Your eng team has API keys.
  • First "hello world": your sandbox creates a test wallet, runs a test money-movement quote, receives a test webhook.
  • Your eng team has orientation. The next block of scope is agreed.

Sandbox integration

  • You integrate the OVAAL SDK into a feature branch of your existing app.
  • First end-to-end flows: test wallet creation, test money-movement execution, test policy-rule creation. The sandbox doesn't settle real fiat; it uses simulated counterparties.
  • Your compliance team reviews the compliance pack. With the DPA signed pre-kickoff, the sub-processor list, legal opinions and an audit-log sample get reviewed in this window.
  • In parallel, any DPA redlines close between your legal team and our counsel. Most partners accept our template with minor edits.

Staging integration

  • Your feature branch deploys to your staging environment.
  • Real-world compliance flows: KYC-ed test users, Travel Rule exchanges through the Travel Rule provider's sandbox, AML screening against the screening vendor's test tier.
  • First real settlement-rail integration through your chosen EMI / SEPA rails partner. Your EMI partnership team provisions the production credentials in parallel.
  • QA pass: your team runs the full feature paths end to end.

Production ramp

  • You promote to production with a limited cohort, usually a small internal or friends-and-family group.
  • Real transactions, real settlement, real compliance checks.
  • Our dedicated integration engineer monitors alongside your on-call through the cohort window.
  • Your compliance team observes: flagged transactions, audit-log anomalies, edge cases.

General availability

  • You open the feature to your full user base.
  • We move from "integration engineer" to a dedicated support channel, with the joint incident runbook active.
  • A post-GA retro is scheduled to capture what actually happened.

The variance is real, and it cuts both ways. A smaller org with decisive eng and compliance leads moves faster than the reference shape. A larger org with more stakeholders and deeper existing-system integration moves slower. The honest framing is weeks rather than quarters, with the exact range falling out of your scope, not out of a number we put in a deck.

What extends the timeline

A few factors stretch the calendar, and I'd rather name them so you can self-assess:

  • Heavy DPA redlining. If your legal team treats the DPA template as the start of a long negotiation, expect extra calendar weeks. Our counsel has worked through similar templates with EU and MENA firms before, so we usually converge, but agreement takes time.
  • No settlement-rail relationship yet. If you're shopping for an EMI / SEPA rails partner alongside the OVAAL integration, that partner's own onboarding (often a couple of months for a new rail) gates your production date for fiat settlement. We can integrate around it, but money movement to fiat can't go live without it.
  • No stable user ID. Our integration needs you to send an opaque user identifier. If your identity system doesn't expose one yet, common in very early-stage partners, that's a prerequisite to fix first.
  • Scope outside V1. US coverage, a licensed custodial model, chains we haven't integrated, or a compliance vendor outside our current set are scope conversations, not a same-shape integration. We'll have those conversations plainly.

What this architecture trades away

  • Depth in any single capability. A specialist wallet SDK will out-feature ours on wallet UX alone. We win on integration reduction and the layer above the rails, not on out-specialising each rail.
  • Self-host on day one. You run on our managed infrastructure by default. Self-host is on the roadmap for partners that need full data residency. If day-one self-host is non-negotiable, raise it on the first call.
  • US coverage. Not in V1.
  • A custodial option. Not part of the product. A partner that needs custody can pair a licensed custodian alongside our orchestration, though that's a heavier commercial conversation.

Bottom line

A control-plane integration measured in weeks rather than quarters isn't a slogan. It's what falls out of four specific decisions: non-custodial by default, one uniform SDK surface, versioning treated as a contract, and compliance inline in the execution path. Each one carries a trade-off we'll name rather than hide. Crypto and account abstraction are the first rail we proved under that layer, not the whole story; the same orchestration extends to fiat and EMI rails.

If those trade-offs fit how you build, the architecture does the work the timeline implies. If they don't, you'll hear that from us on the first call rather than three weeks in. Either way, the fastest way to find out is to put your real scope in front of an engineer.

The clearest next step is to book an architecture review: a scoped technical conversation about control-plane fit, the responsibility split, and your integration path. You can also read how the layers fit together on the platform overview.