# Worked examples Four full-length emails across the personas, each with the brief it answers and a note on why it works. Use these to calibrate register and rhythm - not as templates to fill in. Copying their structure is fine; copying their sentences defeats the purpose. --- ## Example 1 - CEO, insight / point-of-view **Brief:** Position ID Partners on agentic AI in banking; the ask is a leadership briefing. --- **Audience:** CEO **Type:** Insight / point of view **Subject:** Who answers when an AI agent moves money? **Preview:** The accountability question boards have started asking. Hi {{FirstName}}, When an AI agent pays an invoice on a customer's behalf, someone still owns that decision. The question boards have started asking - and APRA will ask soon enough - is who, and on what evidence. Most banks can't yet answer it. The agent acted on a delegation the customer granted months earlier, through systems built to authenticate people, not software acting for them. The gap between those two things is where the accountability sits, and right now it's nobody's. We've spent the past year working on exactly this - how a bank grants, limits and proves an agent's authority - and we've put our view in a short note written for boards rather than engineers. I'd welcome thirty minutes to take you through it before it reaches your risk committee by another route. Regards, David Hyland Director, ID Partners **CTA:** Book a thirty-minute leadership briefing - link to calendar page. --- **Why it works.** The subject is a question the reader can't comfortably answer. The first paragraph puts the consequence before any technology. One specific (APRA) and one sharp framing ("built to authenticate people, not software acting for them") do all the persuasion. 130 words, signed by a person, and the CTA is a conversation - the only ask a CEO email should make. --- ## Example 2 - CISO, nurture follow-up **Brief:** Follow up CISOs who downloaded the CPS 230 readiness guide a month ago; move them towards a readiness workshop. --- **Audience:** CISO **Type:** Nurture follow-up **Subject:** CPS 230 and the identity dependencies nobody mapped **Preview:** The gap most readiness assessments are missing. Hi {{FirstName}}, You picked up our CPS 230 readiness guide last month, so you'll know the standard treats a failed critical operation the same whether the cause was your system or your supplier's. What we're seeing since 1 July is that identity is the dependency most readiness work missed. Authentication and authorisation sit under nearly every critical operation, yet they rarely appear in the operational risk profile as a service with its own tolerances - and third-party IdPs and credential providers seldom make the material service provider register at all. That's an uncomfortable finding to receive from APRA rather than from your own team. We run a half-day working session that maps identity dependencies against your critical operations and leaves you with the evidence in a form your risk committee can use. If the guide was useful, this is the practical next step. Regards, Sarah Chen Principal Consultant, ID Partners **CTA:** Enquire about the identity dependency mapping session - link to services page. --- **Why it works.** Opens by crediting what the reader already knows, then delivers one precise, checkable claim about a gap - no fear-mongering, just an auditor's observation. "Evidence in a form your risk committee can use" speaks the CISO's actual language: assurance, not security theatre. The CTA produces evidence, which is what this persona buys. --- ## Example 3 - Enterprise architect, event invite **Brief:** Webinar, 18 September, on FAPI 2.0 and what it changes for CDR implementations. Invite enterprise and security architects. --- **Audience:** Chief / enterprise architect **Type:** Event invite **Subject:** FAPI 2.0 changes the CDR conversation **Preview:** What Final actually means for your data holder stack - 18 September. Hi {{FirstName}}, FAPI 2.0 reached Final in February 2025, and the interesting part isn't the security profile itself - it's what the simplifications make possible. Dropping the JARM and hybrid-flow complexity of FAPI 1.0 Advanced in favour of PAR, PKCE and sender-constrained tokens takes real cost out of a data holder implementation, and the Attacker Model gives you something FAPI 1.0 never had: a documented basis for arguing with your pen testers. The open question is transition. The CDR standards still bind to FAPI 1.0 Advanced, so the practical decisions - what to build behind an abstraction now, what to let your vendor carry, where DPoP fits against MTLS in your estate - are architecture calls, not compliance ones. That's the ground we'll cover on 18 September: one hour, working from reference architectures we've used with Australian data holders, with the transition decision points laid out against the current Register position. Worth an hour if CDR infrastructure sits anywhere near your roadmap. Regards, Marco Rossi Lead Architect, ID Partners **CTA:** Register for the 18 September session - link to registration page. --- **Why it works.** Assumes fluency - no explanation of what FAPI is - and offers a genuinely reusable distinction (architecture call vs compliance call) plus a dry, knowing line about pen testers. Specifics carry the authority: Final in February 2025, PAR, PKCE, DPoP vs MTLS. At 190 words it's long for an email, right for this reader. --- ## Example 4 - Chief engineer, announcement / practical note **Brief:** Announce a published reference implementation for OAuth 2.0 token exchange (RFC 8693) covering agent-delegation flows; drive engineers to the repo and a hands-on session. --- **Audience:** Chief engineer **Type:** Announcement **Subject:** Token exchange without the bespoke middleware **Preview:** A working RFC 8693 reference implementation, tested against PingFederate. Hi {{FirstName}}, Every team we've worked with this year has solved agent delegation the same way: a bespoke service in front of the token endpoint that mints something almost, but not quite, like a proper token exchange. It works until audit asks who the actor was, and then it doesn't. We've published the reference implementation we now start from instead. Standard RFC 8693 token exchange, with the actor token carried through so the `act` claim survives into the access token - which is the part the bespoke versions always drop, and the part that makes delegation provable later. Tested against PingFederate; the README covers the token processor configuration, which is genuinely the fiddly bit. It's not exotic. That's the point - the boring, standards-shaped version is the one that passes review. If your teams are anywhere near this problem, the repo is here, and we're running a hands-on session next month where you can bring your actual token flows. Regards, Tom Nguyen Engineering Lead, ID Partners **CTA:** Repo link, plus registration for the hands-on session. --- **Why it works.** Opens with a failure mode the reader has personally seen, names the exact defect (`act` claim dropped), and admits which part is fiddly - honesty this persona reads as competence. "The boring, standards-shaped version is the one that passes review" is the engineer's own worldview, stated back. Two links, but one problem and one argument.