This style guide uses a cascading approach. In the first instance, use the guidance described here. If you can't find what you're looking for or need more information, use the Microsoft style guide to resolve any issues. If you're looking for guidance on word usage or spelling, use the Merriam Webster dictionary.

This guide is maintained by Caroline Domenech. If you have questions about anything you see here or would like to provide feedback, contact caroline.domenech@moodys.com.

Accessibility and inclusivity

Moody's wants to write for everyone, everywhere. This means supporting the inclusion of multiple perspectives from diverse audiences. We want to be impartial, non-judgmental, and unbiased. Avoid the assumption that our audiences are a particular gender, race, or class.

We should write thoughtfully, with inclusivity in mind and always consider others' perspectives and lived experiences. Focus on people, speak plainly, and be empathetic.

Accessibility

Avoid using directional words such as above/below, top/bottom, or left/right. These words can be confusing to those using screen readers or assistive technologies. Additionally, these terms can also create challenges for localization, for example navigating in right to left languages. Instead, use words that indicate sequence, such as preceding or following.

Alternatively, orient the user by referring to on-screen signposting. Direct end users to orient themselves by sign-posting with specific buttons, columns or other UI elements instead.

Use the WCAG guidance to see more details around specific issues related to web accessibility.

Inclusivity

Consider using the following alternatives to common terms as a step toward improving inclusivity. Some exceptions may have to be made, such as for industry standard terms like the FATF blacklist.

Anti-racist language:

Alternatives to the white is positive and black is negative comparisons.

• Instead of whitelist, use allow list and instead of blacklist, use block list.
• Permitted/not permitted

Alternatives to master/slave:

• Parent/child or dependent
• Primary/secondary
• Primary/replica
• Leader/follower

Alternatives to ableist language:

• Active/deactivated or inactive instead of enable/disable
• Typical/atypical instead of normal/abnormal

Ungendered language:

• Chair or Chairperson instead of Chairman/woman
• When the subject or person is unknown, use the singular they or you
• Person/individual instead of man/woman

Grammar and mechanics

Abbreviations

Use periods in these common abbreviations: Mr., Mrs., Ms., Prof., or Dr.

Avoid Latin abbreviations as they can be misinterpreted and cause problems for screen readers and localization.

• Use 'that is' instead of 'i.e'.
• Use 'for example' instead of 'e.g'.
• Use 'and so on' instead of 'etc.', or consider removing it, since it can be vague.

Acronyms and initialisms

Unless it's an industry standard term, such as URL or API, spell out the full term on initial use before referring to it as an acronym or an initialism.

Active voice

Choose active voice over passive voice as it is more direct, engaging, and easier to read. In active voice it is clear who or what is doing the action.

Ampersand (&)

Addresses

Use open punctuation in addresses. In other words, leave out nonessential punctation.

For example:

Moody's 1 Canada Square London E14 5FA

If it's not possible to show the address in this format, use commas to separate each line and a period at the end if it is the end of a sentence.

For example: Moody's, 1 Canada Square, London, E14 5FA.

Apostrophes and contractions

Contractions can make writing feel more conversational and friendly, however, they shouldn't be used in a way that makes the content unprofessional or overly familiar.

Bold and underlining

If necessary, use bold sparingly to emphasize text. If you're not sure, then don't use bold. Don't underline copy to highlight it unless it's a URL or email address.

Capitalization

Use sentence case, except when using a proper noun. A proper noun refers to a specific instance of a noun, such as company names, job titles, product names, or peoples' names. If you're unsure whether to capitalize something, don't capitalize it.

Currency

Use two decimal places and put the currency symbol before the amount: $450.00. For currencies that share a currency symbol, for example CAD and USD, combine the use of the symbol with the ISO currency code in the following format: CAD $110.00.

If you need to show a fraction or decimal place, use a 0 and a period: £0.95.

Use commas, not spaces or periods, to indicate thousands: £3,000.

In the UI, where space may be limited, use the symbol to indicate the currency, but include the currency name in a tool tip or hover hint.

Dates

Capitalize the names of months and days and their abbreviations. Use 3 letter abbreviations when needed. Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, and Dec
Mon, Tue, Wed, Thu, Fri, Sat, Sun

Don't use punctuation in dates.

• Today
• Yesterday
• Mon 7 Jun 2025
• 4 Apr 2024

Time

Use AM and PM preceded by a space. Use capital letters for AM and PM.

• 9:23 AM
• 4:23 PM

Displaying date and time together

• Today at 9:23 PM
• Yesterday at 9:23 PM
• Monday 30 September 2024 at 9:23 PM
• Mon 7 Sep 2024 at 9:23 PM
• 30 Sep 2025 at 9:23 PM

Ellipses

Use ellipses in the UI when there are space constraints, but make sure the user's action or task is still obvious and avoid breaking across words.

Error messages

Error messages should be friendly, helpful, and concise. Don't use the words 'please' or 'sorry' and avoid flowery language. An error message should contain a minimum of 3 parts:

1. What happened should be written in plain English, clearly stating the problem. This can be the title or header of the error message. For example: The policy failed to upload.

2. The cause should be written in plain English, without jargon. This briefly summarizes what went wrong. For example: Your policy failed to upload because another upload is already in progress.

3. Include instructions on how to fix the error or the next step a user needs to take to resolve the error. For example: Wait for the previous policy to finish uploading or cancel it and upload the required policy.

Exclamation points

Avoid using exclamation points.

File extensions and sizes

When referring generally to a file extension type, use all uppercase without a period. Include file sizes, where possible, using the number and unit of measurement in capital letters. For example, 50 MB or 250 KB.

Add a lowercase 's' to make an extension plural. For example: GIFs, PDFs, HTMLs, JPGs.

When referring to a specific file, the filename should be lowercase. For example: graphing.gif, ma_benefits.pdf, twitter-profile.jpg, ilovedoughnuts.html.

Jargon and slang

Jargon is specific words used by a profession or group that can be hard for other people to understand. As not all of our customers are familiar with these specialist terms, don't use jargon.

Avoid slang. Such informal language doesn't translate across regions and cultures. In some cases, it may even be considered offensive.

Job titles

Job titles are treated as proper nouns and therefore capitalized.

For example: Prime Minister, not Prime minister and Chief Executive Officer, not Chief executive officer.

Lists and bullets

For lists where the order is unimportant, use standard bullets and a serial comma.

If nested bullets are needed, make sure the bullets alternate in list type.

In an ordered list, use a different numbering system in the secondary level than in the primary level.

Ordered lists should only be used for procedures and sequential events or when the order of items is relevant. For example:

1. Select Create new profile.
2. Enter the individual's details.
3. Select Finish.

Moody's compliance and third-party risk management - use of the name

Moody's should always be spelled out in full.

Example: Moody's provides award-winning solutions to financial risk practitioners globally. Our data, models, software, and expertise empower our customers to better measure, monitor, and manage risk.

The name of the operating unit (OU) should also be spelled out in full, using sentence case. For example: Moody's compliance and third-party risk management team is here to help you automate your anti-financial crime program.

Compliance is capitalized at the start of a sentence or header. However, when appearing as part of the OU name, third-party risk management is hyphenated and not capitalized. If referring to the practice of third-party risk management, the third-party can be capitalized at the start of a sentence. Note that when referring to third parties or a third party, this is not hyphenated.

Names

The names of people with initials should have a space between the initials with no periods. For example: Paul D Smith or P D Smith.

Organizations' names, such as WH Smith, SBC Warburg, IG Metall, have no spaces or periods.

Numbers

Spell out whole numbers from zero through nine. Use numerals for 10 or greater.

This applies to all use cases, except when it comes to millions and billions, which should be spelled out. For example: 8 million.

Phrasal verbs vs nouns

Phrasal verbs are verbs that are made up of more than one word. For example: log on or set up. These can get mixed up with nouns. If it is a noun, these words can be combined, however, if it is a verb, the words are kept separate.

Example:
Noun phrase: Enter your login to access the platform.
Verb phrase: Log in to the platform.

Please and sorry

Avoid adding the words 'please' and 'sorry'; use these words sparingly. Simple, direct language and commands get the message across faster.

Positive language

Write positively.

Product names

Product names should be treated as proper nouns unless otherwise stated. Some brands may contradict this ruling and should be written as per their existing brand rules.

For example: Kompany refers to their cloud-based platform as a KYC workspace whereas Passfort describes their customer lifecycle management solution as Passfort Lifecycle. Both styles should be respected.

Pronouns

This/That/These/It are pronouns. They refer to another noun, but they can introduce ambiguity if it's not clear which noun they're referring to, so use them wisely to make the copy as clear as possible.

You/We/I/My are personal pronouns. Use the pronoun you to talk to and engage the reader directly. Using you as a pronoun helps avoid the passive voice and makes the tone more human.

Using the pronoun we for Moody's Analytics KYC, the business unit, or Moody's more broadly is fine as it can humanize the company, but it might also create confusion about who is included in that we, so write around it where possible.

My and I should be avoided where possible.

Punctuation

Brackets

Avoid brackets in copy. If the text in brackets is important to the meaning of the sentence, use commas instead or break into multiple sentences.

Commas

Use serial commas. Serial commas, or Oxford commas, are commas used before the last item in a list.

Dashes, hyphens, and slashes

Don't add spaces before or after these punctuation marks.

Use hyphens for multi-part words such as up-to-date or read-only.

Periods

End complete sentences with periods in content writing.

In UI and API documentation, if there are one or more lines of text, use periods.

Quotation marks

In American English (AE), all punctuation sits inside the quotation marks.

Ranges

Use the word 'to' to connect number and date ranges.

• Monday 30 September 2024 to Monday 30 September 2025
• Mon 30 Sep 2024 to Mon 30 Sep 2022
• Medium risk: 100 to 500

Spelling

Use American English (AE).

American spelling	British spelling
authorize	authorise
gray	grey
center	centre
liter	litre
analyze	analyse
license	licence
catalog or catalogue	catalogue
program	programme or program
color	colour
enrol	enroll
canceled	cancelled
inquire	enquire

In AE, practice is a noun and a verb. In British English (BE), the verb is practise.

Watch out for license and defense too, which are spelled with an 's' for both the noun and verb in AE and BE uses a 'c' for the nouns.

Refer to www.merriam-webster.com for more information on language usage, especially American spelling.

Tense

Write in the present tense.

Web and email addresses

Email addresses and URLs should appear in lowercase, underlined, and linked. For example info@moodys.com and www.moodys.com.

Don't include http: or https: at the beginning or a URL, but do include the www., and end with a period if the web address or email appears at the end of a sentence.

Help documentation

Audience

Write for the broadest possible audience, assume your readers have strong domain knowledge but may be new to the product. When you write, keep the UX user personas and design principles in mind. Apply basic information architecture principles in order to display information appropriately.

Focus on supporting end-users to self-serve while using the UI but consider also the role that internal stakeholders play. An internal stakeholder may require some support in the form of notes or signposting to additional content.

Formatting

Use the <guilabel> and <guibutton> styles when referring to UI elements. The <guibutton> style should be used to refer to UI elements that the user interacts with directly. For example: Enter the customer's name in the First name field.

Use the <guilabel> element when referring to a UI element that a user is not explicitly interacting with, but you are referring to the UI for orientation or confirmation.

Emphasis

Use italics and bold sparingly, overuse can make it difficult to know which parts of the text are important and may affect assistive technologies negatively.

Headings

Use one H1 per page. Follow the correct order of heading levels: H1, H2, and then H3. Don't follow an H1 with an H3.

Avoid empty headings, duplicated headings, or headings with no related content.

Learn how to front-load your headings and provide the reader meaningful descriptions of the following content. Use the infinitive form of the verb in titles. This is because using a gerund, or -ing form, can be inconsistently translated as well as increasing the cost and character count in localized content.

Interactions with the UI

Use the word 'select' when you're instructing the end user to pick something from a number of choices, such as from a list or dropdown menu.

For example: Select a configuration option.

Use the words 'choose' or 'add' when you're instructing the end user to make a choice that's more open-ended, such as a custom field or free text field.

For example: Choose a decision reason to apply to the application.

Unless there are multiple UI elements with the same label, avoid adding the word 'button'.

Lists

Introduce lists with a lead-in and end the line with a colon. Items in a procedure and numbered lists should be full sentences and end in a period.

• Use a bulleted list for things that have something in common but don't need to appear in a particular order.

1. Use the numbered lists for items, where the number of items is significant, or priority is important. Use the numbered lists with icons for procedures and instructions.

How-to topics

Users that access the how-tos will likely be more familiar with some of the basic concepts of the platform and the compliance industry. A key feature of the how-to section is its anatomy: it should contain clearly written steps; prefaced by a short lead-in that contains any prerequisites for getting started and ending in links to a related concept topic or the reference section.

When creating a new how-to topic, use the template built in Paligo.

How-to headings

Use task-oriented titles that begin with a verb and follow all other heading guidance. Front-load your headings.

Lead-ins or intros

A good lead-in should include context for the feature and include the following information.

• Description of the feature
• The benefit the feature brings to the user
• Prerequisites or caveats

Use meaningful link text that refers to the title of the page or describe the nature of the linked document or webpage instead of using generic link text like, Click here.

Links

Use phrases like Go to or Open to describe link behavior. Use the launch icon from Material icons if you're providing an external link. Example: Go to CIFAS portalopen_in_new

Notes, caveats, and cautions

Notes, caveats, and cautions should always appear immediately following the relevant content. The exception to this is when they apply globally, in which case they should be a part of the lead-in.

Prerequisites

These can be required permissions, links to get started topics, or any other tasks that need to be completed before starting this one. Include prerequisites as a part of your lead-in.

In Paligo, use a sidebar element to create the Prerequisites and assign accordion as the role.

Procedures

Avoid writing long procedures. A good rule of thumb to follow is that procedures should be no more than 7 steps. Consider breaking larger procedures into subtasks or sub-sections.

Sections

Avoid adding more than three related tasks to any one how-to topic.

Tutorial topics

Tutorials provide users with focused details and a limited set of instructions in order to complete a very specific task.

When creating a new tutorial topic, use the template built in Paligo.

Lead-ins or intros

The tutorial introduction should tell the user what they will achieve by following the tutorial. Include details of the specific example the tutorial will follow.

For example: In this tutorial, we will create a sample risk model for product applications by individuals. Applications are assigned a risk level as follows.

Procedures in tutorials

Tutorial steps should be concrete, providing only the minimum necessary information needed to complete the step. An explanation of all the available options should be left for the how-to section. Minimize the number of steps involved in the procedure; consider breaking larger procedures into subtasks or simplifying the tutorial example.

Links

Include links to related information or next steps in a section at the end of the topic. This section can be titled Additional information or explicitly Next steps.

Screenshots

• When taking screenshots, sign in to the product with an account that looks like one a user might see. Avoid using an admin account because it may show employee-only features.
• Screenshots should be taken using Snagit, with Capture Cursor switched off.
• Don't use real names or data in screenshots. Use demo data where possible, else use Snagit's selection tool to remove PII.
• Add a border to each screenshot using the Snagit editor. The border should be light grey (#D7D8D7) with a 3pt width.
  • Crop images to square up edges in modals with rounded corners.
• Where possible, show an image of the modal with as much completed detail as possible.
• Where it would be useful to include a cursor in the screenshot, such as where the accompanying text says "Select X to Y", add the cursor in Snagit using a stamp. This avoids differences in the cursor appearance when screenshots are taken on a Mac versus on a PC. Use either the Cursors-PC-Actual-Size_01 (arrow cursor) or Cursors-PC-Actual-Size-15 (hand cursor) stamps.
• Save screenshots in PNG file format.
• Add alt text via the image description field in Paligo.
• Screenshots should be placed inside the procedure step the screenshot is supporting.
• Avoid adding text boxes as Snagit flattens the image on saving. Text added to images won't be accessible, searchable, or translatable. Consider using steps and providing the accompanying text in the Paligo topic.

Callouts

• Avoid using more than two callouts in a single screenshot.
• Callouts should have a 4px outline in #E35205 (Moody's secondary color: orange) in the first instance. If there is a contrast/clashing issue, use #5C068C (purple). The fill color should be #FFFFFF (white). Use GT America Regular font in #000000 (black). No shadow.
• Highlight elements in a screenshot using a square shape with rounded corners, #E35205 (orange) outline 3px, no shadow.
• For steps, use GT America Regular font in #FFFFFF (white), #E35205 (orange) fill, no additional border, no shadow.

Tables

Large tables should be added to the Reference section with a lead-in and links to the relevant related sections.

Voice and tone

What are voice and tone?

Voice and tone are the way we communicate Moody's compliance and third-party risk management personality to our audiences. We aim to be clear, bold, and perceptive. Avoid jargon, superlatives, and long sentences; our copy is easy to read and is representative of Moody's.

Voice

Our voice reflects who we are and the communities we serve. We should sound like Moody's compliance and third-party risk management, no matter if we are writing microcopy, user guides, a blog, or a website.

Clear Plainspoken, concise

We convey information in a succinct, easily understandable way, providing a voice of reason.

• Write as clearly as possible, without introducing ambiguity or relying on jargon
• We don't need to use hyperbole or overpromise in our messages
• Simplify anything complex and try to improve readability

Perceptive Trustworthy, informed

We pay close attention to the world around us and our customers' needs, unlocking opportunity to inspire better decisions for a better future.

• Offer customers and audiences the most up-to-date information
• Write at a level that appeals to your audience that has varied skill sets and capabilities
• Continue to evolve our language and content based on user feedback

Dynamic Innovative, solutions-oriented, optimistic

We have a strong point of view, acting as a trusted guide in a rapidly changing world.

• Write positively
• Provide valuable, practical advice for your audience

Tone

Tone conveys mood. It's the way we express our attitude and evoke specific feelings in the reader. Tone should be adapted to the context of the message. For example, in an error message our tone should be informative and helpful to guide the reader; in a blog, the tone should be informative, yet conversational.

This table shows examples of voice and tone in context. Moody's compliance and third-party risk management voice and tone should be balanced, bearing in mind the business unit's place within the wider Moody's brand.

Too formal	Too casual	Just right
Select the Remove button in order to update the Verification list.	Hit the Remove button to get rid of the person from the Verification list.	Select Remove to update the Verification list.
Ensure that any previous imports have been canceled before uploading a new one.	Don't upload a new policy until you have canceled the old ones.	Make sure that you have canceled ongoing imports before trying to upload a new policy.
The Configure and send request modal allows you to view and deselect the forms that you intend to send to the customer.	Look at forms you're sending to the customer in the Configure and send request modal.	The Configure and send request modal shows you which forms you are sending to the customer.

Localization

Our content should be easy to translate, accessible and understandable to a culturally diverse audience. This section provides guidance for writers on best practices when creating content with internationalization and localization in mind.

• Use simple and clear language: Aim for a version of English that is internationally understandable. Avoid complex sentence strutures and be direct.
• Use plain words.

• Use sentence case.
• Avoid idioms and colloquialisms: Phrases that are specific to a particular language or culture may not translate well or could be misunderstood.
• Write in the active voice and present tense where possible.
• Use articles to identify nouns.

• Avoid long noun strings: The longer a noun string is, the more difficult it is to read and translate.

• Use consistent terminology: Consider adding technical terms to the help site and/or Lokalise glossaries.

Technical writing

• Use neutral examples and references: Examples or references shouldn't favor a particular region, culture, or belief system. Avoid references to holidays or historical/political events that may not be globally recognized.
• Be mindful of date formats, currency, and units of measurement. When possible, use an international standard or clearly specify the format being used.
• Re-use content: Consistency improves clarity, and recyling content reduces the translation cost.
• Avoid Latin abbreviations. Use acronyms sparingly, spell out the full term on first use for non-standard terms.

UX writing

• Consider space for text expansion in UI elements: Some languages take up more space than English. Allow for 30% more text in UI elements.
• Avoid concatenated strings where possible. This can create issues in languages with different grammatical structures.
• Avoid splitting strings around another UI element For example, "Expire after" input_field "days". "Expire after" and "days" are added as separate strings in Lokalise, which makes translation more complicated.
• Don't add punctuation programmatically. For example, use "Phone number:" not "Phone number"+":". Different languages may use different forms of punctuation or different spacing.
• Don't use flags to represent languages: Flags are symbols that represent countries, not languages.
• Be aware of the cultural significance of color. For example, red is associated with danger in western cultures, while it symbolizes luck in some Asian culutures.