Guidewire Oracle Fusion Integration — Real-Time and Batch

A guidewire fusion integration is the ongoing, continuous data flow between Guidewire InsuranceSuite (PolicyCenter, BillingCenter, ClaimCenter) and Oracle Fusion Financials — not a one-time migration. Where a migration runs once to move historical data, an integration runs continuously to keep the two systems aligned: new policies issued in PolicyCenter flow to Fusion as revenue recognition source transactions; new claim payments in ClaimCenter flow to Fusion as AP invoices and paid-loss GL journals; new receipts in BillingCenter flow to Fusion as AR receipts; reinsurance cessions flow as ceded GL postings and reinsurer AR/AP entries. The guidewire fusion integration supports both real-time and batch patterns per data domain with bidirectional reconciliation feedback.

The integration architecture supports both per data domain. Real-time / near-real-time (5-15 minute latency) uses Guidewire's Cloud APIs and event streams to push individual transactions to Fusion via REST API — used for claim payments (treasury needs same-day cash position) and high-value premium issuances (large commercial accounts wanting same-day revenue recognition). Batch (hourly to end-of-cycle) uses Cloud Data Access (CDA) Parquet exports and FBDI bulk loaders — used for high-volume small-ticket flows (personal auto premium, homeowners claim payments) where 1-hour latency is acceptable and FBDI's higher throughput is preferred. Most P&C carriers run a hybrid — some domains real-time, others batch — and the guidewire fusion integration supports both simultaneously without operational duplication.

Yes — and bidirectional flow is required for several P&C scenarios. Forward (Guidewire → Fusion): premium, paid-loss, cash, commissions, ceded reinsurance flow downstream. Reverse (Fusion → Guidewire): treasury-confirmed payment status returns to ClaimCenter so adjudicators know when a claim payment cleared; bank-reconciled cash receipts return to BillingCenter so producer ledgers reflect cleared status; Fusion-side suspense-account resolution returns to BillingCenter for cash-application correction. The reverse flow typically uses Fusion's REST API + event streams paired with Guidewire's Cloud Messaging API to keep the two systems aligned. The guidewire fusion integration supports both forward and reverse with full reconciliation feedback so no flow is fire-and-forget.

Near-real-time premium recognition handles the case where large commercial accounts (large property schedules, complex commercial liability) are issued in PolicyCenter and need immediate revenue recognition in Fusion — sometimes within the same business day. The integration flow: PolicyCenter event fires on policy bind; Syntra ETL captures the event via Guidewire Cloud Messaging; transforms to Fusion Revenue Recognition source transaction; pushes via Fusion REST API within 5-15 minutes; Fusion's Revenue Recognition module kicks off earning-schedule calculation; written-premium GL posting happens within the same close period. Critically the upstream PolicyCenter policy lifecycle is unaffected — the event fires on bind regardless of whether Fusion is up, and the integration handles back-pressure (if Fusion REST is unavailable the event is queued and pushed when service resumes).

Claim payment push is the highest-volume real-time flow in most P&C integrations. The flow: adjudicator authorises a payment in ClaimCenter; ClaimCenter event fires on payment-issue; Syntra ETL captures the event via Guidewire Cloud Messaging; checks Fusion for existing claimant supplier (creates if needed via Supplier REST API); transforms to AP Invoice via crosswalk; pushes via Fusion AP Invoice REST API; Fusion AP Open Invoice Validation runs; payment-ready status returned to ClaimCenter via Cloud Messaging reverse flow. Total latency typically 5-15 minutes from adjudicator authorisation to Fusion AP. The integration handles claimant-supplier-creation dependency automatically so the adjudicator never sees an error — the supplier is created at the right point in the flow without operator intervention.

Reserves are NOT posted as Fusion financial transactions — but they DO need to be reflected in Fusion for actuarial reporting roll-up. The reserve sync pattern: ClaimCenter reserve change events captured via Cloud Messaging; transformed to Fusion evidence metadata payloads; pushed to Fusion paid-loss GL records as supplementary attributes (ReserveAmount, ReserveDate, ReserveUser, ReserveReason); also pushed to the long-tail Parquet archive partitioned by claim per coverage per accident-year for actuarial loss-triangle reconstruction. Fusion's GL itself is unchanged — paid-loss GL accounts only show actual paid-loss; reserve information is supplementary metadata on those records. The guidewire fusion integration ensures the reserve metadata is current — actuaries querying Fusion always see the latest reserve balance per claim per coverage.

Reinsurance bordereaux cycles are typically monthly or quarterly per treaty. The integration flow: ceded premium accrued in PolicyCenter per policy per treaty per layer is batched per bordereaux cycle; ceded loss recovery accrued in ClaimCenter per claim per treaty per layer is batched per bordereaux cycle; at bordereaux cycle close, Syntra ETL extracts the cycle data from Guidewire; transforms to Fusion Ceded GL postings + Reinsurer AP/AR entries via crosswalk; loads via FBDI Journal Import for the GL postings and FBDI AP/AR Invoice Import for the reinsurer entries; reconciles the cycle per treaty per reinsurer to the cent; produces the bordereaux pack for delivery to the broker. The bordereaux cycle is preserved unbroken through the integration — treaty settlements never fail because of integration timing issues.

Yes. The guidewire fusion integration is one of several downstream consumers of Guidewire data — most P&C carriers also feed an actuarial data warehouse, a BI / analytics platform, regulatory reporting tools, fraud detection systems and reinsurance broker portals. The Syntra ETL extraction layer is multi-consumer by design: a single CDA + Cloud API extraction feeds all downstream consumers from a unified canonical event stream. Fusion is one consumer; the data warehouse is another; BI tools subscribe to specific topics; regulatory reporting subscribes to the regulatory-relevant subset. This eliminates the consultant-led pattern where each downstream consumer has its own bespoke extraction pipeline — five extraction pipelines for five consumers, all hitting Guidewire independently with five times the operational burden.