Compliance Jobs Report: oct. 30. What better way to celebrate Halloween than with the Compliance Jobs Report? This week Radical Compliance has a changing of the guard at American Express, plus new hires at GoFundMe, the University of Minnesota, Crypto.com, LEGO, and more. Also promotions at Baker Hughes, Cox Enterprises, and Akamai Technologies; plus job leads in oncology, food, and lab work. Radical Compliance gather the Jobs Report news items from LinkedIn, press releases, and wherever else Radical Compliance can find tips - and thank you to everyone who sends them in, you make the Jobs Report possible! If you have any gossip to share (even confidentially) email me at [email protected] or find me on LinkedIn. Compliance Jobs. This week Radical Compliance begin with a changing of the guard at American Express. First, Allan Gallo is stepping down as chief audit executive, after nearly 40 years in various roles at the company (basically, his whole career). He had been chief audit executive since 2019. Succeeding him will be Geoff Rusnak, who has been chief audit director at Wells Fargo since 2020. Gallo's retirement comes just weeks after federal banking regulators fined Amex $350 million for various anti-money laundering failures, and the internal audit team caught its share of criticism in the settlement. GoFundMe, the online crowdfunding website, has hired Stephanie Parks as chief compliance officer. Parks joins the site after seven years as chief compliance officer at Fiserv. Kimberly Otte has been hired as chief compliance officer at the University of Minnesota, starting January 2027. Otte has been chief compliance officer of Amazon Health Services since 2022, and she got both her undergraduate and law degrees from the University of Minnesota. Go golden gophers! Debbie Cline has a new job as vice president of global compliance and ethics at Georgia-Pacific. Cline had previously been general counsel of Invista, a mid-sized chemicals manufacturer, since 2024. Crypto.com has named Mohammed Mortajine chief compliance officer. Mortajine arrives at the crypto trading platform from Paysafe, where he had also been chief compliance officer. Nicolas Dimier just snapped into place at LEGO Group as a senior compliance manager in its London offices. Dimier comes to LEGO after 18 years at Hasbro, most recently as director of quality assurance and regulatory affairs. FinWise Bank in San Francisco has deposited Mark Webb onto the payroll as chief compliance officer. Webb previously worked at Coastal Community Bank as senior fintech compliance director since 2023. Marco Antonio Tapia has joined farm equipment manufacturer CNH as legal and compliance specialist in the company's Mexico subsidiary. Tapia comes to CNH after 18 months at Grupo Truper, another manufacturing business, where he had been conflicts of interest manager. Gauntlet, a cryptocurrency decentralized finance startup, has hired Nick Colón as head of compliance. Colón comes to Gauntlet after three years at Stripe, where he most recently was chief integrity officer. Ruchita Selukar is another who just left Stripe, where she had been compliance lead. She just joined Agora, a small fintech firm dabbling in stablecoins, as senior manager of anti-money laundering compliance. (One wonders how folks in that line of work feel today, amid the biggest cryptocurrency heist in history.) The Supply Register, a staffing firm in Britain that caters to the education sector, has hired Niki Dunn as head of quality and compliance. Dunn joins Supply Register from Morgan Hunt, another British recruitment firm, where she had been head of compliance. Barclays Private Bank has hired Santosh Talada as vice president and head of financial crimes compliance in its Dubai operations. Talada glides into Barclays after four years at DBS Bank as an assistant vice president for compliance. Collectors, a business that helps to verify the authenticity of coins, trading cards, and other collectibles out there, has hired Sergio Fernandez as global senior manager of trade compliance. Fernandez previously worked at FIFA managing customs and international freight issues for the World Cup this summer. Berkshire Money Management, a money management firm in western Massachusetts, has brought aboard Max Mejiborsky as deputy chief compliance officer. Mejiborsky had actually been working with BMM for many years as a consultant already as part of National Regulatory Services. Cody Russell is the new compliance manager at Gusto, a mid-sized software development firm based in San Francisco. Russell previously worked at Norm AI as a compliance reviewer. MassMutual has tapped Dimitri Lorenzon as chief risk officer. Lorenzon joins the insurance giant after four years at MetLife, where he most recently was U.S. chief risk officer and head of stress testing. First Bank of Nigeria has hired Ruth Ike as head of information security, risk, policies, and compliance. Ike joins the bank, one of the largest in Nigeria, from First City Monument Bank, where she most recently had been head of information governance, policies, and procedures. Software startup Blitzy just picked up Paulina Zgorzelska as head of GRC. Zgorzelska was last seen at Snyk, another software development firm, where she had been senior director of risk, compliance, and trust until last April. Devon Energy has hired Brandy Weldon as lead audit professional. Weldon previously worked at Gulfport Energy Corp. as accounts payable manager. And Annabelle Rodan has been hired at Bet365 as a compliance analyst. Rodan previously worked at Debt Recovery Plus as a compliance assistant. Moving up the ladder. Energy giant Baker Hughes has promoted Fernando Contreras from chief compliance officer to general counsel of the company's industry and energy tech division. Contreras had been CCO since early 2025; not clear to Radical Compliance yet who succeeds him in that role. Renata Giuliani is moving up at Akamai Technologies, from associate general counsel for Latin America to ethics and compliance senior director for the same region (and also still associate GC, but adding "compliance" to your title is automatically a promotion). She's based in Brazil. Cox Enterprises has promoted Jeff Handler, from senior counsel and privacy lead at Cox Automotive to assistant general counsel for privacy and cybersecurity for the whole enterprise. Home healthcare provider HarmonyCares has promoted Wendy Dietz from clinical trainer to compliance advisers. Milestones. Somber news in the internal audit world: Grant Ostler, a long-time voice in the field, passed away the other week at the age of 65. Ostler most recently had been an industry principal at Workiva until he retired this spring, and earlier in his career he was a senior internal audit executive at Ceridian Corp., EcoLab, Northern Tier Energy, and elsewhere. Ostler was a delightful presence on the internal audit conference circuit and will be missed. Vendors & service providers. CareCloud, a provider of revenue management software to the healthcare industry, has named Mitchell Brie as chief compliance officer. Brie previously ran Empower Healthcare & Compliance, a compliance services firm in the healthcare sector, which CareCloud acquired earlier this year; in addition to his CCO duties for the firm he'll also still head its compliance advisory business. Open Req Orders BeOne Medicines is looking for an associate director of global trade compliance. Job can be remote, although BeOne is based in Silicon Valley. Salary range is listed at $138,000 to $188,000. Hormel Foods is hiring an ethics and compliance manager. Job is based in Austin, Minn., which is suburban Minneapolis. Salary range is listed at $103,000 to $144,000. One assumes you can also scarf down a steady supply of free food in the office. Charles River Labs is looking for a chief compliance officer. Job is based in Wilmington, Mass. in suburban Boston; salary range is $320,000 to $350,000. Compliance meme of the week. That's all for this week's report. As always, if you have a tip or want to brag about your new job, promotion, career milestone, or anything else, email me at [email protected] or find me on LinkedIn. I'm always happy to give credit to the many hard-working people here in its corner of the business universe.

Stripe's customer portal just got its own pause button. It captures zero data on why anyone used it. Stripe shipped native self-serve pausing in the customer portal on Oct 28. It skips your cancellation flow entirely and logs no reason why. On October 28, Stripe quietly added a pause button to its own customer portal. Set features.subscription_pause.enabled to true on a portal configuration and your subscribers get a native way to pause their own subscription - no code, no webhook, no UI you had to design. For a company that sells a cancellation flow for a living, this is the kind of change you can't skim past. Stripe just built a competing self-serve path to the exact moment its product exists to own. Share of subscribers who return after pausing, instead of canceling outright That number is exactly why Stripe building a native pause path matters so much. Pause isn't a minor convenience feature - it's one of the highest-leverage retention moments in the whole subscription lifecycle, and now there are two separate doors into it: whatever you've built into your cancellation flow, and a new one Stripe ships for free that you don't control. What actually shipped on October 28. The mechanics are simple, which is part of the point. Enable features.subscription_pause on a portal configuration, and the redesigned customer portal - the newer portal experience Stripe has been rolling out through 2026, not the legacy embed - gains a pause action for any subscription under that configuration. You can also deep-link straight to it: create a portal session with flow_data.type set to subscription_pause and the subscription ID in flow_data.subscription_pause.subscription, and the customer lands directly in the pause flow instead of the portal's main menu. That's the same deep-linking pattern Stripe already uses for subscription_cancel, subscription_update, and the customer_update flow CancelFlow wrote about in September. Under the hood, this calls the same pause mechanism Stripe introduced as a dedicated API in May 2026 - a real paused status on the subscription object, distinct from active, with no invoices generated while the pause is in effect. CancelFlow covered that endpoint in detail in its piece on Stripe's paused subscription status. What's new isn't the pause mechanism itself. It's that Stripe now puts a button in front of the customer that calls it directly, with nothing of yours in between. Stripe built subscription_cancel and subscription_pause as parallel features in the same portal configuration object, but they're not peers in how much control you get over them. Pull up the API reference for both and the gap is obvious: | Capability | subscription_cancel | subscription_pause | | Reason capture | cancellation_reason object - fixed 5-option enum, plus custom feedback_options | None - no reason field exists on the object at all | | Timing control | mode: immediately or at_period_end | No mode field - pause takes effect when the customer confirms | | Proration handling | proration_behavior: none, create_prorations, always_invoice | No proration field - pausing stops billing, nothing to prorate | | Duration control | N/A - cancellation is permanent by default | duration.type: indefinite, or interval_options up to 3 years | | Default if you just flip "enabled" No reasons collected unless you also enable cancellation_reason | A single one-month pause option, no reason collected | The pattern is telling. Every control Stripe gave you over cancellation - why, when, how the money gets handled - is missing from pause. Pause shipped as a scheduling primitive: how long, and whether there's a limit. It did not ship as a retention-intelligence feature, even though pause is fundamentally a retention action. The default is the shortest option, and nobody's reason gets recorded. Two details here are easy to miss if you just flip the flag and move on. First, if you enable subscription_pause without configuring duration at all, Stripe defaults to interval_options with a single choice: one month. Not 30, 60, and 90 days as options - one month, full stop, unless you explicitly build the array yourself. A subscriber who needs six weeks, or who'd take an indefinite pause if offered one, doesn't see that choice. They see one button. Second - and this is the part that should bother anyone running a cancellation flow - nothing about the pause event tells you why it happened. Compare this to what CancelFlow wrote about the Feedback Options API Stripe shipped for cancellations two weeks earlier in the same Endive release: that feature exists specifically so you can collect a custom reason when someone cancels through the portal. Stripe clearly understands that capturing a reason has value. It built that capability for cancel and chose not to extend it to pause, which is either an oversight or a signal that pause is being treated as a billing-state toggle rather than a retention signal worth measuring. Either way, the practical effect is the same: a subscriber can pause through the native flow, and the only thing your webhook on customer.subscription.paused will ever tell you is that it happened - not whether it was "too busy right now," "can't afford it this month," or "don't need it until next quarter." Those are three completely different subscribers who need three completely different follow-ups, and the native flow collapses all of them into a single undifferentiated event. What a reason-blind pause button misses Not using it enough 28% Too expensive right now 22% Switching to a competitor 14% Missing a feature they need 12% Share of stated cancel reasons across CancelFlow deployments. Source: why customers cancel. Those four reasons alone call for different responses - a usage nudge, a temporary discount, a roadmap conversation, a feature workaround - and a pause offer that's actually matched to the reason converts far better than a generic one, exactly the logic its own post on pause vs. discount vs. downgrade lays out. Stripe's native button can't make that match. It has nowhere to store the information it would need to. Two self-serve paths now lead to the same place. Here's the structural problem this creates. If you've built a pause offer into your own cancellation flow - shown it only to subscribers who selected a matching reason, tracked its acceptance rate, measured how many people who pause actually come back - that flow only runs when a subscriber goes through it. But subscribers reach Stripe's hosted portal through other doors too: a "manage billing" link in your app, a dunning email (its own guide to Stripe dunning explicitly recommends linking every failed-payment email straight to the portal), or a receipt footer. If subscription pausing is enabled on the portal configuration behind any of those links, a subscriber can now pause themselves the moment they land there - before your reason-based targeting ever sees them, and without your save-rate tracking ever recording the event as an offer you made. That's not a reason to avoid the feature. A native pause option is still better for a subscriber than no pause option, and it's better than a cancellation you never get a chance to intercept. But it means the portal configuration itself has become a decision you need to make deliberately, not a default you inherit by checking a box. What to actually do about this. Three concrete options, depending on how your product is set up: * Leave it off on any configuration reachable outside your cancellation flow. If a given portal configuration is linked from dunning emails, receipts, or a generic "billing" link in your app, keep subscription_pause.enabled false there. Let pause live only inside the flow where you actually capture a reason and can route it to the right follow-up. * If you do enable it, configure the duration deliberately. Don't ship the one-month default by accident. Match your interval options to what your own data says subscribers actually need - if your cancellation flow already offers 30/60/90-day pauses, mirror those exact windows so a subscriber gets the same choice regardless of which door they walked through. * Treat the pause webhook as a blind spot, not a clean signal. Any customer.subscription.paused event that didn't originate from your own flow should get flagged in your churn dashboard as reason-unknown, not folded into whatever bucket your flow-driven pauses land in. Mixing the two quietly corrupts every acceptance-rate number you're using to decide which offers actually work. If you're trying to put a number on what a portal-only pause costs you in lost targeting, its retention rate calculator is a quick way to see how much a few extra points of blind, unmeasured saves are actually worth against your current churn baseline. And if your cancellation flow doesn't have a reason-matched pause offer in it yet, that's precisely the gap a tool like CancelFlow is built to close - pausing the right subscription, through the right offer, with the reason attached, instead of leaving it to whichever door the customer happens to walk through first. Frequently asked questions. What is Stripe's new subscription pausing feature in the customer portal?+ How do I enable and configure subscription pausing in Stripe's customer portal?+ Does Stripe's native portal pause feature collect a reason for pausing?+ How is this different from the dedicated pause/resume API endpoints Stripe shipped in May 2026?+ Try CancelFlow Stop losing subscribers today. One script tag. One function call. A live cancellation flow in under 10 minutes.

Stripe added 51 new webhook events on Oct 28. Most subscription code still infers them from one. Stripe's Oct 28 release ships ~51 named webhook events for subscriptions and invoices, replacing the diff-it-yourself model most dunning code runs on. Right now, almost every integration that reacts to a Stripe subscription change is listening for one event - customer.subscription.updated - and then writing code to figure out what actually happened inside it. Did the subscription just go past due? Did a seat get removed? Did the customer's trial end? Stripe fires the same broad event for all of it and hands you a previous_attributes diff to sort out the rest yourself. On October 28, 2026, Stripe shipped a fix for that specific problem, and it's the kind of release that matters more to dunning and churn tooling than most Stripe announcements do, even though it never mentions churn once. new named webhook events Stripe added for subscriptions, invoicing, and schedules on Oct 28, most replacing a diff against one broad event What actually shipped on October 28. Stripe's webhook system has long had two event flavors. A snapshot event - the kind almost every integration still runs on - sends the entire resource object in the payload along with previous_attributes, a field that holds only the old values of whatever properties changed. To know what actually happened to a subscription, your handler has to read the current object, cross-reference it against those old values, and reconstruct the business meaning: "status flipped from trialing to active" or "an item disappeared from the items array." That reconstruction logic lives in production code at thousands of SaaS companies, and it's fragile in exactly the way any hand-rolled diff is fragile - it breaks quietly when Stripe adds a field, and it treats a dozen genuinely different business events as the same notification with different shapes. The October release doesn't just make events thinner - Stripe already had thin equivalents of snapshot events for that. It adds new event types that didn't exist before, each one named for a single business fact instead of a generic "something updated" signal. On the subscription side alone: v1.customer.subscription.active, past_due, trialing, unpaid, incomplete, and incomplete_expired cover status transitions directly. item_added, item_removed, item_price_changed, and item_quantity_changed cover what happened to a specific line item inside the subscription, rather than leaving you to diff the whole items array. default_payment_method_changed and cancel_at_changed cover two of the most operationally important subscription fields in isolation. On the invoicing side, v1.invoice.discount_added, discount_removed, and three line-item events do the same job for invoices, and v1.promotion_code.fully_redeemed fires the moment a promo code runs out of uses. | What you had to do before | What fires now | What it tells you without guessing | | Listen for subscription.updated, check if status === "past_due" v1.customer.subscription.past_due | This subscription just entered dunning - trigger your failed-payment sequence now, not on the next poll | | Diff the items array between old and new object | v1.customer.subscription.item_removed | A seat or line item was dropped - a contraction signal your MRR math never sees until the next invoice | | Check previous_attributes.trial_end against the current value | v1.customer.subscription.trialing | The subscription is in trial right now - no object diffing required to know it | | Diff invoice.discount against the prior invoice | v1.invoice.discount_removed | A discount just came off this invoice - the moment to check if the customer notices the new price | | Poll the PromotionCode object or wait for a support ticket | v1.promotion_code.fully_redeemed | A retention offer code just ran out of redemptions and silently stopped saving anyone | Why the seat and discount events matter more than the status ones. The status events get the attention because dunning is the obvious use case - a direct past_due notification is a cleaner trigger than parsing it out of Stripe's dunning retry schedule indirectly. But the quieter wins are item_removed, item_quantity_changed, and discount_removed, because those are exactly the signals that seat-based churn and discount-driven churn hide from most monitoring today. A team plan that drops from 40 seats to 32 doesn't cancel anything - nobody hits a cancel button, nothing shows up in a churn survey - but it's contraction revenue that most dashboards only catch at the next invoice reconciliation, if they catch it at all. An item_quantity_changed event firing the moment it happens gives you a same-day signal instead of a 30-day-later one. The discount events do something similar for a problem CancelFlow has covered before: the discount cliff, where a subscriber churns the moment their promotional price reverts to full price. Today, catching that requires knowing your own discount schedule and watching the calendar. A v1.invoice.discount_removed event fires at the exact moment the price reverts on a real invoice, which means you can fire a retention touchpoint - an email, an in-app notice, a one-time offer - timed to the actual billing event instead of an internal reminder that might be a day or two off from what Stripe actually billed. v1.promotion_code.fully_redeemed solves a related and more embarrassing gap: if you're running a win-back or retention-offer promo code with a redemption cap, this is the first native signal that tells you the code is dead before a customer tries to use it and hits an error. Share of the 51 new event types, by product area Subscriptions & schedules 35% Invoicing 22% Financial Connections 20% Pricing & catalog 16% Entitlements & promotions 8% What it actually takes to receive one of these. This isn't a flag you flip on an existing webhook endpoint. Thin events - semantic or otherwise - are delivered through a separate API v2 concept called an Event Destination, not the classic webhook endpoints most integrations already have configured. To receive v1.customer.subscription.past_due, you create a new destination with event_payload: "thin" and subscribe it to that specific type, either in the Dashboard under Developers | Webhooks with "Use thin events" toggled on, or via a POST to /v2/core/event_destinations. The notification you receive is deliberately minimal - the event type and a reference to the related object, not the object itself - so your handler fetches the current state with fetchEvent or fetchRelatedObject when it needs more than "this happened." Stripe's own migration guidance is explicit that you shouldn't cut over all at once. The recommended path is to stand up the new destination alongside your existing one, run it in shadow mode - logging what you'd do without writing anything - for 24 to 48 hours, then cut over with idempotency keys to handle the brief overlap window where both destinations fire for the same underlying change. That overlap matters operationally: it's the same at-least-once delivery problem CancelFlow has written about before, just now running across two event systems simultaneously instead of one, which makes the deduplication discipline in its webhook reliability piece more relevant during migration, not less. The part this doesn't fix. Naming the event correctly doesn't eliminate the extra API call. A thin event still only tells you what kind of thing happened and where to look - you fetch the related object separately to read its current state, which means every one of these new signals costs you a round trip you didn't need with a snapshot event's full payload already sitting in the request body. For a handler that already fetches fresh state anyway (which is the correct pattern, since a snapshot payload can be stale by the time you process it), this is a wash. For a thin, high-volume handler that was leaning on the snapshot payload to avoid an API call entirely, it's a real latency and cost tradeoff worth measuring before you migrate every event type at once - which is exactly why Stripe recommends migrating type by type rather than flipping the whole integration over in one deploy. None of this replaces the reconciliation job you should already be running against the Stripe API independent of any webhook, thin or snapshot - a more precise event name tells you faster that something happened, but it still depends on delivery succeeding, and at-least-once delivery can still duplicate or delay a notification regardless of which payload format carries it. What it does change is how much custom diffing logic has to exist between "Stripe fired an event" and "my product knows what that event meant," which for the seat, discount, and status signals above is exactly the gap that turns a delayed churn or dunning reaction into an on-time one. Getting that upstream signal right before it reaches a churn calculation or a health score is worth more than most teams credit it - and for the subscribers who do make it to a cancel screen, having clean, current subscription state is also what lets CancelFlow decide which save offer to show, instead of guessing from data that was already a few hours stale. Frequently asked questions. What is the difference between a Stripe thin event and a snapshot event?+ Do I have to migrate my existing Stripe webhooks to use the new semantic events?+ What are Stripe's new semantic subscription events?+ How do I receive a Stripe thin event like v1.customer.subscription.past_due?+ Try CancelFlow Stop losing subscribers today. One script tag. One function call. A live cancellation flow in under 10 minutes.