If you're a CTO at a MiCA CASP, a VARA-licensed broker, an EMI launching crypto, or a wallet provider adding automation, you've probably scoped the in-house build at least once. The number you landed on was somewhere between 12 and 18 months of focused engineering work, plus 1 to 2 compliance hires who understand MiCA and EU TFR Article 14 well enough, plus ongoing maintenance as vendors deprecate APIs, as regulations evolve, and as the stack's sub-processor chain requires quarterly attention.

You probably also scoped the bundle-of-specialists alternative. ZeroDev for AA, Onramper for ramp aggregation, Notabene for Travel Rule, Chainalysis for AML, a custom bill-pay path that talks to Modulr's API, and session-key logic you write yourself. That's 4 to 6 contracts, 4 to 6 integration cycles, 4 to 6 sub-processor paperwork loops, 4 to 6 teams to maintain relationships with, and 4 to 6 places where an API change can break your product.

The third option is us: one SDK, one contract, one integration engineer from our side, one integration cycle of 4 to 8 weeks. I want to walk through how that's actually possible architecturally. The design decisions we made, the trade-offs we accepted, and what it takes to integrate.

The non-custodial-by-default anchor

The single architectural decision that makes the 4 to 8 week timeline achievable is non-custodial-by-default. Every other decision cascades from this one.

When you integrate OVAAL, end-user funds never enter OVAAL's custody or your custody. The end-user has a smart-contract wallet (ERC-4337) with signing authority bound to their passkey or MPC share. Transactions are initiated by the end-user (directly or via session-key-scoped automation rules). The funds stay on-chain the entire time. OVAAL orchestrates, signs with paymaster keys where needed for gas sponsorship, and generates audit-log events, but never holds the assets.

Why this matters for integration time:

  • No custody integration work. If OVAAL held custody, every partner would need to work through the partner-to-custodian relationship. KYC, KYB, account opening, segregated asset accounts, reconciliation pipelines, audit hooks. That's weeks of compliance and engineering work per partner. Non-custodial skips it entirely.
  • Cleaner liability posture. Your compliance team's review is faster when the question "who holds the funds" has the answer "the end-user, directly, on-chain." No fiduciary layer to validate. No contingent custody agreements.
  • No licensed trust requirements. Custodial crypto infrastructure requires either being a licensed custodian or working with one. Both add months. Non-custodial infrastructure doesn't need that path.

The trade-off: end-user UX is responsible for passkey or MPC-share security. We mitigate this with AA-native recovery flows (passkey plus social plus MPC) that are better than a seed phrase for most users. But we can't pretend it's the same liability profile as a custodian holding funds. It isn't, and compliance teams who want a licensed custodian should pick Fireblocks, not us. We say this 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 wallets, ramps, bill-pay, automation, compliance. You write the auth code once. It handles every capability.
  • 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 eng team reads our SDK documentation for the first time, they learn one surface. Two or three days of focused reading lets a competent engineer navigate every capability we ship. We measure this. We ask partners in their retro how long orientation took. The median is 2 days. The 90th percentile is 5.

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 specialist-vendor integrations, compliance is an add-on. You integrate a wallet SDK, you integrate a ramp SDK, and then you bolt Notabene on top of both so your transactions have Travel Rule data attached before they go on-chain. The integration is manual. Your code has to route the Travel Rule call at the right moment, handle Notabene's response, retry on failure, and make sure the audit log captures the exchange.

In OVAAL, the compliance stack is inline in the execution path. When you call ovaal.wallets.transfer(...) or ovaal.billPay.execute(...), the compliance checks happen as part of the operation. Travel Rule exchange (Notabene or 21 Analytics, you pick), AML screening (Chainalysis or TRM, you pick), sanctions list check, risk scoring. If any of these fail, the transaction doesn't execute. 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) via partner-portal configuration, and the execution path enforces it automatically.

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.

Trade-off: you give up the flexibility to swap in a third compliance vendor OVAAL hasn't integrated. If you need Elliptic instead of Chainalysis or TRM, we can prioritize the integration with you as a co-development, but it's not a drop-in today.

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
+----------------------------+
|  Sub-processor chain       |
|  - Circle (USDC/EURC)      |
|  - Notabene / 21 Analytics |
|  - Chainalysis / TRM       |
|  - EMI partner (SEPA)      |
|  - 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

No arrows from OVAAL's boxes to anywhere that would hold end-user funds. The architecture is deliberately flat. You own the "above OVAAL" layer (UI plus identity plus ledger). The end-user's keys own the "below OVAAL" layer (signing plus custody). OVAAL is the middle layer that orchestrates. Orchestration is the thing that takes 18 months in-house but can be done in 4 to 8 weeks of integration against a vendor who's already built it.

The actual integration timeline

Week-by-week, what you do:

Week 1: kickoff

  • Signed MSA and DPA in hand.
  • Day 1: architecture walkthrough call with your eng lead, compliance lead, and BD lead.
  • Day 2-3: sandbox environment provisioned. Your eng team has API keys.
  • Day 4-5: first "hello world." Your sandbox creates a test wallet, runs a test ramp quote, gets a test webhook.
  • End of week: your eng team has orientation. Next two weeks' scope agreed.

Weeks 2-3: sandbox integration

  • You integrate the OVAAL SDK into a feature branch of your existing app.
  • First end-to-end flows: test wallet creation, test ramp execution, test bill-pay rule creation. Sandbox doesn't actually settle fiat (uses simulated counterparties).
  • Your compliance team reviews the compliance pack. DPA signed pre-kickoff; sub-processor list, legal opinions, audit log sample reviewed in this window.
  • Parallel: DPA redlines closed between your legal team and our counsel (if any). Most partners accept our template with minor modifications.

Weeks 4-5: staging integration

  • Your feature branch deploys to your staging environment.
  • Real-world compliance flows: actual KYC-ed test users, actual Travel Rule exchanges (with OVAAL's test Notabene/21 Analytics sandbox), actual AML screening (Chainalysis/TRM test tier).
  • First real EMI-partner rail integration (Modulr, Banking Circle, or whoever you chose). Your EMI partnership team provisions the production EMI credentials in parallel.
  • QA pass: your QA team runs through the full feature paths.

Weeks 6-7: production ramp

  • You promote to production with a limited cohort (usually 50 to 500 internal or friends-and-family users).
  • Real transactions, real settlement, real compliance checks.
  • OVAAL's dedicated integration engineer monitors alongside your on-call for 2 weeks of cohort operation.
  • Compliance team observes: any flagged transactions, any audit-log anomalies, any edge cases.

Week 8: GA

  • You open the feature to your full user base.
  • OVAAL transitions from "integration engineer" to "dedicated support channel." Joint incident runbook active.
  • First post-GA retro scheduled 30 days later.

The variance is real. Some partners hit GA in week 5 or 6. Smaller orgs with decisive eng and compliance leads. Some hit in week 10 or 11. Larger orgs with more stakeholders and more existing-system integration depth. 4 to 8 weeks is the honest target. Plus or minus 2 weeks is the honest range.

What makes the timeline fail

A few factors extend the timeline, and I want to name them so you can self-assess:

  • Your legal team wants to rewrite the DPA. If your legal team treats the DPA template as a starting point for heavy redlining, expect 2 to 3 extra weeks. Our counsel has negotiated with most major EU and MENA law firms on similar templates. We can usually converge, but it's calendar time.
  • You don't have an EMI relationship yet. If you're starting to shop for Modulr, Banking Circle, Clear Junction, or Paynetics alongside OVAAL integration, the EMI side's timeline (typically 6 to 12 weeks for a new rail relationship) gates you. We can integrate without the EMI, but you can't go to production on bill-pay without it.
  • Your existing identity stack doesn't expose a stable user ID. Our integration requires you to send us an opaque user identifier. If your identity system doesn't yet expose one (common in very early-stage partners), you need to fix that before integration.
  • You want features outside our V1 scope. If you want US support, a licensed custodial option, chains we haven't integrated, or a compliance vendor we don't work with, it's a scope conversation, not a 4 to 8 week integration. We'll have that conversation honestly.

What this architecture trades away

  • Depth in any single capability. ZeroDev's AA SDK has more features than ours. We win on integration reduction, not AA depth.
  • Self-host day one. You run on our managed infrastructure by default. Self-host is available for Enterprise-tier partners who need full data residency. If day-one self-host is non-negotiable for you, talk to us on the first call.
  • US coverage. Not V1.
  • Custodial option. Not part of the product. If you need it, use a licensed custodian alongside (partnership pattern: Fireblocks plus OVAAL for enterprise partners who want custody plus our orchestration, though that's a heavier commercial).

Bottom line

The 4 to 8 week integration timeline isn't a marketing claim. It's a consequence of specific architectural decisions. Non-custodial by default, one uniform SDK surface, versioning as a contract, compliance inline in the execution path. Every one of those decisions has trade-offs we're honest about.

If the trade-offs fit your architecture requirements, the timeline is real. If they don't, we'll tell you on the first call that we're the wrong vendor.

Get the integration brief. We'll send the 1-pager and book a 30-minute call.