What implementation actually looks like

Signing is the easy part.

The hardest part of Positive Pay isn't choosing a vendor. It's the implementation — and most community FIs have no mental model for what it involves. The product is straightforward. The coordination is not.

The multi-party coordination map.

A typical Positive Pay implementation involves up to five organizations:

Your FI owns the project, the configuration decisions, and the business client onboarding.

Your Top Core Provider has to support the connection that gets decision data into the core. This is often the longest pole.

Your Major Digital Banking Provider has to support the single sign-on so business clients reach Positive Pay without a separate login.

Your teller capture platform comes into play if you want in-branch check validation.

The fraud vendor configures their side and supports the integration build.

Implementation is the work of getting all five aligned on scope, sequence, and timeline. No single party controls the whole chain.

What custom integration work costs.

Some integration work is standard and included. Some is custom — and custom work has a price. Custom work requests at the core level can run into the thousands or tens of thousands of dollars, depending on scope.

Two things reduce this cost. First, ask whether your fraud vendor has a partner status with your core that can subsidize or productize the integration. Second, ask whether the integration work, once built, can be reused for other FIs on the same core — some FIs negotiate cost-sharing arrangements for integration work that benefits the broader client base.

A realistic timeline.

A standard implementation without deep custom integration can be quick: configuration, file setup, and internal training in a couple of weeks. Add core integration, single sign-on, and teller capture, and the timeline stretches. A realistic range for a fully integrated deployment is several weeks to several months, driven mostly by the partners' development queues — not the fraud vendor.

Plan for testing. Build in a testing window before go-live, and test under realistic conditions, including parallel use by multiple staff at once if you have a teller integration. Issues that don't surface in single-user testing surface in production.

Do this

Before your implementation kickoff, draw the five-party coordination map for your specific FI and identify which party owns each dependency. The map is your project plan.

What's next.

Lesson 5.4 goes deep on the single most common integration challenge: the Decision File.

Self-check

3 quick questions

What's the hardest part of a Positive Pay implementation?

A Choosing a vendor

B The multi-party coordination across the FI, core, digital banking, teller capture, and fraud vendor

C Writing the disclosure

D Pricing

Correct. The product is straightforward. The coordination across up to five organizations — each with their own queue and priorities — is the hard part.

Not quite. The hardest part is the multi-party coordination. Getting the FI, core, digital banking, teller capture, and fraud vendor aligned is the real work.

What can reduce the cost of custom core integration work?

A Nothing, it's fixed

B Asking about vendor-core partner status and whether the work can be reused or cost-shared

C Skipping testing

D Using a smaller core

Correct. A fraud vendor with partner status at your core can subsidize the integration. Work that can be reused across FIs on the same core can be cost-shared.

Not quite. Ask whether your fraud vendor has partner status with your core, and whether the integration work can be reused or cost-shared with other FIs.

What mostly drives the implementation timeline for a fully integrated deployment?

A The fraud vendor's speed

B The partners' development queues

C The disclosure review

D The number of business clients

Correct. Core and digital banking integration are the long poles. The fraud vendor is usually ready quickly — it's the partners' queues that stretch the timeline.

Not quite. The partners' development queues — especially the core and digital banking provider — are what drive the timeline, not the fraud vendor's speed.

← PreviousDefault decisions, cutoffs, and SLAs Next lesson →The Decision File and core integration